Tiers and pricing
On this page
Understand limits and pricing
AI Studio enforces rate limits to keep the service stable. These limits vary by subscription tier and determine the volume of requests and tokens you can consume. Choosing a tier isn’t just an administrative checkbox: it’s a decision that directly impacts your costs and how your application behaves during peak hours.
The two types of limits
Mistral applies two simultaneous controls on every workspace. Hitting either one causes your calls to fail. The first, Requests Per Second (RPS), caps the number of API requests sent per second; exceed it, and the API returns a 429 Too Many Requests error. The second concerns tokens per minute and per month: it measures the volume consumed for both input and output, applies at the workspace level, and is shared among all users with access. A team of six developers working on the same key burns through this quota six times faster than a solo developer, a fact that is systematically overlooked during the first traffic spike.
The fix takes just a few lines: when a 429 occurs, wait before retrying, and increase the wait time with each attempt rather than hammering the API.
import time
from mistralai.client import Mistral
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
def call_with_retry(messages, max_retries=3):
"""Basic rate limit handling with exponential backoff."""
for attempt in range(max_retries):
try:
return client.chat.complete(
model="mistral-large-latest",
messages=messages
)
except Exception as e:
if "429" in str(e) and attempt < max_retries - 1:
wait = 2 ** attempt
print(f"Rate limit reached, waiting {wait}s...")
time.sleep(wait)
else:
raise
Subscription tiers
The Free API Tier, also called Experiment, is designed for exploration. Its RPS stays low, around a few requests per second, and its monthly token volume is limited; all models remain accessible, but with reduced quotas, no SLA, and no dedicated support. It works perfectly for discovering Mistral models, prototyping an application, or running functional tests—and it will quickly teach you what a 429 feels like if you try to run a client demo on it.
The paid Scale tier is built for production. RPS is higher to absorb real traffic, the monthly token volume is expanded, and billing switches to usage-based beyond the subscription, with standard technical support. This is the expected level for a production application with moderate to high traffic, for a professional development team, and generally whenever you need predictable performance.
Finally, the Enterprise tier is negotiated custom with the Mistral sales team. It unlocks personalized limits, a guaranteed SLA on availability and latency, dedicated support with a technical point of contact, access to Dedicated Serverless and Self-Hosted options, and tailored contractual terms—including a Data Processing Agreement (DPA) and GDPR compliance. This is mandatory when your own clients contractually require service commitments from you.
Check your current limits
The exact values applying to your workspace aren’t guessed: they are listed in the admin dashboard.
https://admin.mistral.ai/plateforme/limits
There you will find your RPS limits per model, your token consumption per minute and per month, the history of that consumption, and alerts triggered as you approach thresholds. Make it a habit to open this page before any announced scale-up, rather than after the first incident.
Optimize your costs
The most effective lever is model choice, since not all models cost the same per token. Reserve Mistral Large 3 for complex tasks—reasoning, long-form generation, analysis of contractual documents—and assign simple processing like classification or field extraction to Mistral Small. When latency matters more than response nuance, Ministral 3 is worth testing.
# Simple task → lightweight model
response_simple = client.chat.complete(
model="mistral-small-latest",
messages=[{"role": "user", "content": "Classify this text: positive or negative?"}]
)
# Complex task → powerful model
response_complex = client.chat.complete(
model="mistral-large-latest",
messages=[{"role": "user", "content": "Analyze this contract and identify problematic clauses."}]
)
Consumption itself can then be reduced in small steps. A concise system prompt saves tokens on every call, not just once; max_tokens caps response length and avoids costly digressions; streaming doesn’t lower the bill but significantly improves the experience for long responses; finally, caching answers to recurring questions on the application side eliminates the call entirely.
Of course, you have to measure it. Log the tokens for every call: without this instrumentation, you will discover the cost overrun when the invoice arrives.
import logging
logger = logging.getLogger("mistral_usage")
def tracked_call(model, messages):
response = client.chat.complete(model=model, messages=messages)
usage = response.usage
logger.info(
f"Model: {model} | "
f"Input tokens: {usage.prompt_tokens} | "
f"Output tokens: {usage.completion_tokens} | "
f"Total: {usage.total_tokens}"
)
return response
When to move up a tier
Four signals should trigger a conversation with Mistral: recurring 429 errors, monthly consumption reaching 80% of the quota, a need for an SLA to present to your own clients, or the processing of sensitive data requiring isolation. The first of these four is enough; the other three rarely arrive alone.
Key takeaways
- Limits apply at the workspace level (RPS + tokens/minute/month)
- The free tier is sufficient for prototyping; the Scale tier is for production
- Check your exact limits at
admin.mistral.ai/plateforme/limits - Optimize costs by choosing the model suited to each task
- Implement exponential backoff to handle rate limiting in production