The pricing shape of La Plateforme
La Plateforme prices per million tokens, quoted separately for input and output. Output is more expensive because it is generated one token at a time; input is cheap because it is a single forward pass over the KV cache. Every model — Mistral Large, Small, Codestral, Ministral, embed — gets its own line on the price sheet at console.mistral.ai. Read those numbers as your absolute worst case: batch and prompt-cache discounts sit on top.
Where the money actually goes
- Input tokens: system prompt + user turns + tool JSON + retrieved context. Long RAG contexts dominate here.
- Output tokens: the model's reply. Terse system prompts ("reply in one sentence") save real money.
- Embeddings: billed per million input tokens; there is no output side.
- Batch API: async requests with a 24h SLA get a meaningful discount over live inference.
- Fine-tuning: a training charge plus a modest per-token premium for calls to the tuned model.
Estimating a Mistral workload before you commit
Rule of thumb: 1 token is roughly 4 characters of English. Take your average request length in characters, divide by 4, multiply by your daily QPS × 86,400, and apply the per-million rate. Do this for input and output separately — most people underestimate output tokens by 3-5× because they forget the model's reply plus any tool_call JSON is fully billed. Add a 30% safety margin the first month; retire it once actuals arrive.
Levers that reduce your Mistral bill
- Cache system prompts server-side where possible; prompt caching cuts repeated input cost dramatically.
- Use the Batch API for anything that does not need to be live (evals, back-fills, offline scoring, embedding refreshes).
- Route easy turns to Mistral Small; escalate to Mistral Large only when a cheap classifier says the turn is hard.
- Truncate RAG contexts aggressively — most passages contribute nothing above top-k = 5.
- Cap max_tokens on outputs; a runaway reply is the single most common surprise on the monthly invoice.
- Instrument per-endpoint token usage in your logs so you can spot the outlier route that eats 40% of the bill.
Batch API economics
The Batch API accepts JSONL files of requests and processes them within a 24-hour SLA at a meaningful per-token discount. If a workflow tolerates async — nightly summarization, back-fills, evaluation runs, embedding refreshes for a search index — batch it. The savings are often the difference between a viable feature and a shelved one.
Embeddings and mistral-embed
Embeddings are billed per million input tokens with no output side, which makes them the cheapest surface on La Plateforme. Because vector index refreshes are usually async, batch every embedding job. If you are recomputing an index on every deploy, cache aggressively — a document that has not changed does not need a new vector.
Compare vs OpenAI and Anthropic
At the flagship tier, Mistral Large sits below GPT-4-class list prices while playing in the same benchmark tier. Mistral Small is competitive with GPT-4o-mini and Claude Haiku. The exact ratios shift quarter-to-quarter, so re-price your workload on real traffic every couple of months. Mistral's EU-hosted default is a genuine differentiator for teams with data-residency constraints.
Reading your invoice
The console breaks down usage by API key, by model, and by request type. Tag your keys per environment (dev/stage/prod) and per feature so surprise bills are attributable in one click. Set spending caps in the console the day you take a payment method live — this is the cheapest insurance you'll ever buy.
EU-hosted defaults and regional pricing
Mistral's default hosting is in the EU, which for many customers is a compliance win rather than a pricing lever. Regional endpoints do not usually carry a per-token premium, but egress costs, cross-region latency, and legal-review time all count against a workload's real total cost. If your app already runs on EU infrastructure, you get zero-friction data residency; if it runs in US-east, add a couple of milliseconds of round-trip to your latency model. That trade almost always still favors Mistral for EU customers.
Instrumenting token usage in production
Every Mistral response includes a `usage` block with prompt_tokens, completion_tokens, and total_tokens. Log all three per request, tagged with the endpoint that generated it, and pipe them into whatever observability stack you already use. Within a week you'll know which product surface is eating your budget and whether Small-tier routes are quietly escalating to Large in production without your knowing. This is the single most useful piece of infra you can add before your first invoice arrives.
When to negotiate an enterprise deal
Once your monthly spend crosses roughly five figures, it is worth asking Mistral sales for a committed-use discount. Enterprise contracts typically bundle higher rate limits, priority support, and a discount on the per-token list price in exchange for a minimum monthly commitment. Bring a clean usage report — the same one your invoice-attribution work produces — and you'll leave the meeting with a rate the self-serve tier does not show. Below that threshold, staying on self-serve keeps you nimble.
Worked cost example: 1M input, 1M output tokens
Take Mistral Small at illustrative rates of $0.20 per million input tokens and $0.60 per million output tokens (check console.mistral.ai for current numbers). One million input tokens costs $0.20; one million output tokens costs $0.60; total $0.80. The same volume on Mistral Large at illustrative $2.00 input and $6.00 output is $8.00 — exactly the 10× ratio the pricing page implies. Now run the same math with the Batch API discount (typically ~50%): Small drops to about $0.40, Large to about $4.00. Multiply by your daily volume to see the annual delta. A workload doing 500M input and 200M output tokens per day on Small live is roughly $130/day, or ~$47k/year — small enough to self-serve. The same on Large is ~$1,300/day, or ~$475k/year — firmly in enterprise-negotiation territory.
Batch vs realtime pricing decisions
Any workload that tolerates a 24-hour turnaround belongs on the Batch API. That includes nightly report generation, evaluation runs across a golden set, back-fills after a schema change, embedding refreshes for a search index, and offline scoring of historical data. Realtime pricing only makes sense for turns that a user is actively waiting on. A common cost mistake is running evaluation jobs against the live endpoint because it is easier to script — moving those to batch typically cuts eval infrastructure cost in half with zero user-visible impact. Structure your codebase so switching a call site from live to batch is a one-line change; you will use it more often than you expect.
Tier recommendation by company stage
Startup (under $2k/mo spend): stay entirely on Mistral Small for user-facing turns, use Batch API for everything async, do not fine-tune yet — a good system prompt is cheaper. Scale ($2k–$20k/mo): introduce the Small-first, escalate-to-Large pattern, add per-endpoint token instrumentation, cache system prompts, request quota bumps proactively. Enterprise ($20k+/mo): negotiate a committed-use discount with Mistral sales, consider fine-tuning Small for your top two or three use cases, run a formal monthly cost review with per-team attribution, and evaluate self-hosting open-weight releases (Mixtral, Codestral Mamba) for the workloads where data residency or per-token economics justify the ops overhead.
How to estimate your monthly spend
Pull one week of production logs. For each endpoint that hits Mistral, compute mean input tokens, mean output tokens, and requests per day. For each row, cost per day equals (mean_input × input_rate + mean_output × output_rate) × daily_requests ÷ 1,000,000. Sum across endpoints, multiply by 30, and add a 30% safety margin for growth and variance. Split the total by model so you can see where the escalation architecture is (or is not) paying off. Re-run monthly — pricing changes, and workload mix shifts more than teams expect. If the number surprises you, the fix is almost never 'switch providers' and almost always 'cap max_tokens, tighten system prompts, and move async work to batch'.