Mistral API Pricing: Rates, Modes, and Real Cost

The short answer

Mistral bills the API per million tokens, with input and output priced separately, and what you pay turns on two choices: which model, and which serving mode. On Mistral's official rate card, verified September 17, 2026, Mistral Small 4 is $0.15 per million input tokens and $0.60 per million output. Mistral Medium 3.5 is $1.50 in and $7.50 out. Same API, same call shape, a tenfold spread on input.

Mode moves the number again. Batch processing is half price. Cached input tokens on repeated prompts carry a 90 percent reduction on the input side. Regional inference on a global or EU endpoint adds 10 percent. Priority inference is offered as a mode for fast, predictable compute, but the pricing page publishes no rate for it, so you have to ask sales.

The rate card is the easy part. What it cannot tell you is how many times your workflow will call the model for work that never needed a model in the first place.

Mistral API pricing at a glance

Rates below are token prices from mistral.ai/pricing/api, read on September 17, 2026. Mistral does not print an effective date on that page, so treat every figure as a snapshot and re-read the source before you commit a budget.

| Model | Input / 1M tokens | Output / 1M tokens | Notes | Verified | |---|---|---|---|---| | Mistral Small 4 | $0.15 | $0.60 | Cheapest general text model | 2026-09-17 | | Mistral Large 3 | $0.50 | $1.50 | Output cheaper than Medium 3.5 | 2026-09-17 | | Mistral Medium 3.5 | $1.50 | $7.50 | Highest published output rate | 2026-09-17 | | Codestral | $0.30 | $0.90 | Code-focused | 2026-09-17 | | Ministral 3 (3B) | $0.10 | $0.10 | Flat in/out | 2026-09-17 | | Ministral 3 (8B) | $0.15 | $0.15 | Flat in/out | 2026-09-17 | | Ministral 3 (14B) | $0.20 | $0.20 | Flat in/out | 2026-09-17 | | Mistral Embed | $0.10 | n/a | Input only | 2026-09-17 | | Codestral Embed | $0.15 | n/a | Input only | 2026-09-17 | | GLM 5.3 (third party) | $1.40 | $4.40 | Served via Mistral, not a Mistral model | 2026-09-17 |

Two things in that table are worth pausing on. Mistral Large 3 is cheaper than Mistral Medium 3.5 on both sides, which breaks the naming intuition most people bring to a rate card. And the Ministral line prices input and output identically, so an output-heavy job that would be expensive on Medium 3.5 changes character entirely on a 3B or 8B model.

Not everything is token-billed. OCR 4.1 is $4 per 1,000 pages and Document AI is $5 per 1,000 pages. Voxtral Mini Transcribe is $0.003 per audio minute, the realtime variant is $0.006, and Voxtral TTS is $0.016 per 1,000 characters. Fine-tuned classifier models carry $1 per million training tokens plus $2 per model per month in storage, with a $4 minimum job fee. Mistral Moderation 2 is listed as free. Enterprise APIs are described as available at 75 percent above list pricing on select APIs, which is a surcharge and not a discount.

Is Mistral AI API free?

There is no open free tier on the API itself. What Mistral publishes is credit bundled into its subscription plans: the free plan includes $10 per month in API credits, Pro includes $30, and the verified-student plan includes $15. Moderation 2 is free, and Leanstral is listed as free in Labs for a limited feedback period. Everything past the bundled credit bills at API rate.

Standard, batch, and priority modes

Mode is the second axis of the price and the one people misread. The terms, as Mistral uses them:

Input tokens are what you send: system prompt, retrieved context, conversation history, tool schemas, the user's message. Output tokens are what the model generates, and on most models they cost more, in Medium 3.5's case five times more. Cached input tokens are repeated prefix content the API recognizes from an earlier call and discounts by 90 percent on the input side. Standard is the default synchronous path. Batch is asynchronous submission for work with no latency requirement, at half the standard price. Priority is a paid path for fast, predictable compute. Regional inference pins execution to a global or EU endpoint and adds 10 percent.

Batch is the discount most workloads leave on the table. Overnight document classification, backfill enrichment, and scheduled scoring runs have no user waiting on them, and moving them to batch is a configuration change rather than a rewrite. Batch is wrong the moment a human is blocked on the response.

Cached input rewards prompt architecture. A stable system prompt and a stable retrieved-context block at the front of every call are cacheable; the same content shuffled or interleaved with per-request data is not. Put the volatile part last.

Do not mix terms across rows. A rate you read for one model on standard pricing is not the rate for a different model, and a batch price is not a standard price with the regional surcharge applied. Every quote is a triple of model, mode, and region, and dropping any leg of it produces a forecast that is wrong in a direction you will not notice until the invoice.

How to calculate a real request

Start with one call. For a single request the token cost is:

cost_call = (T_in × P_in / 1e6) + (T_out × P_out / 1e6)

Where T_in is the full input token count and T_out the generated count. T_in is where estimates go wrong, because it is not the user's message. It is:

T_in = T_system + T_tools + T_history + T_retrieved + T_user

A 40-token question with a 900-token system prompt, four tool schemas, six turns of history, and three retrieved documents is a several-thousand-token input. Scaled to a workflow:

cost_api = N × R × cost_call × M_mode × M_region

N is requests per period, R is the retry multiplier (1 plus your observed rate of timeouts, refusals, malformed structured output, and guardrail rejections), M_mode is 0.5 for batch and 1 for standard, M_region is 1.10 for a pinned global or EU endpoint. Apply the cache reduction only to the cacheable share of T_in, not to all of it.

That gets you the API line. Four cost categories sit outside it, and only one is on the rate card:

1. API cost. The formula above. Model, mode, region, retries.
2. Tool cost. Billed separately from the model. Code execution and web search are each $30 per 1,000 calls, image generation is $100 per 1,000 images, premium news is $50 per 1,000 calls, library indexing is $1 per million tokens plus $0.01 per call, and data capture is $0.04 per million tokens. An agent that searches the web twice per task is paying $60 per 1,000 tasks before a single token is billed.
3. Infrastructure cost. Vector store, queue, orchestration runtime, egress, logging and retention. This does not appear anywhere on a model provider's page and it does not go away when token prices fall.
4. Human review cost. The most expensive line in most production agent workflows, and the easiest to leave out. If 12 percent of outputs need an operator to check them, that percentage times a loaded hourly rate belongs in the model, and a cheaper model that pushes review rates up is a false economy.

Our wider framework for costing a model workflow goes deeper on the retry and review terms. If you are choosing between tiers rather than committing to one, routing by model tier lets the 3B model take the easy share and reserves Medium 3.5 for the calls that actually need it.

Mistral API cost versus agent cost

Here is the structural problem with reading any rate card as a cost forecast. In the formula above, N is the variable that grows, and in a re-reasoning agent N grows with usage forever. The agent receives a task, thinks through it, calls tools, produces an answer, and keeps none of the reasoning. Tomorrow the same task arrives and the same tokens get spent again. Token price is a unit cost. Agent cost is a unit cost multiplied by how many times you pay it, and most of those payments buy a conclusion you already reached.

Look at what a typical triage workflow actually does. It reads an inbound message, extracts a few fields, checks them against a rule set, writes a record, and routes to a queue. Field extraction is judgment. Everything after it is arithmetic and a lookup, and arithmetic priced at $7.50 per million output tokens is arithmetic you are overpaying for. The rule check does not get better by being re-derived. It gets slower, less consistent, and billable.

The correct move is to stop sending that work to a model. When the deterministic share of a workflow runs as code, N for the model drops to the ambiguous cases only, and the rest runs at the cost of compute rather than the cost of inference. Cost becomes front-loaded and then flat: you pay reasoning tokens once while the pattern is being worked out, and after that volume grows against code. That is an architectural property, not a discount, and it is the one lever on your bill that does not depend on a vendor's next price change.

This is also where the state question lands. A workflow that keeps its history in a context window pays to refill that window on every run. A workflow that keeps durable state in an app database reads it for free.

The Major take

The constraint is real and it is not solved by picking the cheapest row on the rate card. Mistral's pricing is legible, batch and cached input are genuine reductions, and Ministral at $0.10 in and out is about as cheap as metered inference gets. None of that changes the shape of the curve. As long as repeatable work runs through the model, spend rises with volume, and every retry, every refilled context window, and every re-derived rule check is billed again.

Major resolves it by changing what the model is for. When a Major agent works out how to handle a repeatable part of a task, it builds an app for that part and runs the app from then on. Take the scheduled triage workflow: the agent builds an app that holds the classification taxonomy, the routing table, the processed-message log, and the escalation rules, with its own managed database and audit trail. On each run the app does the extraction lookups, the deduplication, the writes, and the routing. Mistral gets called only for the messages the rules cannot resolve, and for drafting the reply that needs judgment. In the formula, N collapses to the ambiguous share while total volume keeps growing, T_in shrinks because history lives in the app rather than the prompt, and R falls because deterministic code does not produce malformed structured output. The model does less. It does not do nothing, and the escalation path is the part you most want a good model on.

That is the difference between a cheaper model and a cheaper system. Reason once, run forever. Every app an agent builds this way is code with permissions and logs, reusable by anyone else in the organization, which is also what makes coordinating multiple agents something you can audit rather than something you hope about.

If you are sizing a Mistral bill for a recurring workflow right now, the useful next step is to separate the judgment calls from the lookups and see how little of it genuinely needs a model. Build the app that handles the deterministic share, keep Mistral for the ambiguous cases, and watch the curve flatten as volume grows. Get started on Major and build the app your triage workflow keeps paying a model to re-derive.

Related articles

• DeepSeek vs ChatGPT: The Cost Gap and What to Move
• Kimi vs Claude: Open Weights, Real Costs, Current Models
• AI Coding Agent: What Happens After the Code Is Written