Mistral Large's Context Window and Output Limit

Mistral documents one number for Mistral Large and it is a number for the whole request: prompt, tools, history and generated answer share it. That is the part that decides how you budget, and it is not what the headline figure looks like it means.

The documented figure

Mistral Large 3, version v25.12, is documented with a 256k token context window on Mistral’s model card for the release, which also gives the API name mistral-large-2512, an architecture of 41B active parameters out of 675B total, an Apache 2.0 licence and a release date of 2 December 2025. The same card lists pricing at $0.5 per million input tokens and $1.5 per million output tokens.

Two things about that number are worth being precise about before you plan around it. First, “256k” is 256 thousand tokens, not characters and not words — see which tokenizer version your text is being counted with, because the same string does not produce the same count across tokenizer generations. Second, it is a ceiling on the whole conversation as the model sees it on a given call, which is where the output limit question actually lives.

Why there is no separate output limit

People come to this question expecting a second number, because several providers publish one: a context window of X and a maximum completion of Y, with Y much smaller. Mistral’s model card does not publish a Y. That is not an omission you should route around by guessing; it reflects how the endpoint works.

The max_tokens parameter in Mistral’s chat completions reference is documented as “the maximum number of tokens to generate in the completion”, with a default of null. Null means you have not asked for a bound, so generation runs until the model emits a stop token, hits one of your stop sequences, or runs out of window. The generated tokens are appended to the same sequence the prompt occupies. There is one budget, and output eats into whatever the prompt did not use.

The practical consequence is that your effective output limit is a quantity you compute, not one you look up:

available_output = context_window - prompt_tokens

# 256,000 - 190,000 = 66,000 tokens of headroom
# 256,000 - 255,000 = 1,000 tokens of headroom

A request that fills 255,000 tokens with a retrieved corpus has room for roughly a thousand tokens of answer, and no error will tell you that in advance — the request is valid, it simply cannot produce a long reply. If you need a guaranteed answer length, reserve it explicitly by trimming the prompt to context_window - desired_output before you send.

What is left after a real system prompt

Here is a derivation for a realistic agent request. Every figure below is an assumption about your application, labelled as such; the only sourced number is the 256,000 window.

• Window (sourced): 256,000 tokens, per the Mistral Large 3 model card.
• System prompt (assumed): 1,200 tokens. That is a substantial one — role definition, formatting rules, a handful of worked examples.
• Tool schemas (assumed): 2,000 tokens for eight tools at roughly 250 tokens each. Mistral’s known limitations page states that tool descriptions count toward token usage and caps tools at 128 per request, so this line grows fast in an agent.
• Reserved output (assumed): 4,000 tokens, because you want a full answer rather than whatever fits.

256,000  window
 -1,200  system prompt
 -2,000  eight tool schemas
 -4,000  reserved for the answer
────────
248,800  available for conversation history and retrieved context

The headline number survives contact with a fixed overhead almost intact — the overhead is about 2.8% of the window. This is the useful thing about a very large window and it is worth stating plainly: at 256k, the system prompt stops being the thing you optimise. What consumes the window is accumulated turns and retrieved documents, both of which grow without bound unless something truncates them.

Run the same arithmetic against a 32,000-token model and the overhead is 22% before a single message. That is why the advice you find online about ruthlessly compressing system prompts reads as dated: it was written for windows an order of magnitude smaller.

What happens when you go over

Mistral’s known limitations page states that requests exceeding the model’s context window return a 400 Bad Request. It is a rejection, not a truncation — the API does not silently drop your oldest messages to make the request fit, which is the correct behaviour and occasionally a surprise to anyone who has used a client library that does the trimming for them.

So the failure mode is loud on the way in and quiet on the way out. Too much input gives you a 400 you can catch and handle. Too much input relative to the answer you needed gives you a 200 and a truncated reply, and the only signal is the finish_reason on the choice, which reports length rather than stop when generation stopped because it ran out of room. Log that field. An application that ignores finish_reason cannot distinguish a complete short answer from a decapitated long one.

Knowing your size before you send

Both failure modes above are avoidable if you know the prompt’s token count before the request leaves your process, and this is where people reach for a rule of thumb that does not survive contact with real input. “Four characters per token” is an English-prose approximation. It understates JSON, understates source code, and understates non-Latin scripts badly, which are precisely the three things a 256k-window request is likely to be full of.

The reliable method is to tokenize locally with the tokenizer the model ships, using Mistral’s mistral-common package, and to tokenize the rendered request rather than the concatenated strings. The chat template wraps each message in control tokens, tool schemas are serialised into the prompt, and none of that appears if you count the raw content fields. Skipping it will have you convinced you are at 250,000 tokens when the server sees more.

After the fact, the authoritative number is on the response. Every non-streaming completion carries a usage object with prompt_tokens, completion_tokens and total_tokens; streamed responses only include it if you ask, by setting stream_options.include_usage on the request. Log prompt_tokens per call and keep a distribution of it. The number worth watching is not the mean but the ninety-ninth percentile, because the 400 you eventually get comes from the tail — a conversation that ran long, a retrieval that returned an unusually large document, a user who pasted a log file. A p99 that is drifting toward the window is weeks of warning; a mean that looks comfortable is no warning at all.

The corresponding budget decision is what to do when the tail arrives. Truncating oldest-first is the common default and the worst one for agents, because the oldest turn is often the one that stated the task. Summarising older turns into a compact note, or dropping retrieved context before dropping conversation, both preserve more of what the model needs. Whichever you choose, choose it deliberately — the alternative is a 400 in front of a user.

The older Large models and their windows

If you are reading a benchmark or an old integration, the number in front of you may be for a model that no longer exists. Mistral’s models overview maintains a deprecated list with retirement dates, and the earlier Mistral Large releases are on it. The 2024-era Large models were documented at 128k; Mistral Large 3 doubled that to 256k, which is now also the documented figure for Mistral Small 4 (mistral-small-2603) and Mistral Medium 3.5. The line has converged on one window size, which was not true a year ago.

Two consequences. If you pinned a dated version string — and you should, see pinning a Mistral model version — your window is whatever that version documented, not whatever the current flagship documents. And if you are using a -latest alias, your window can change under you without a deploy, in the generous direction so far, but a change nonetheless.