Codestral's Context Window and What It's Tuned For

Codestral 25.08 documents a 128k token context window. For a model whose job is completing the line you are currently typing, that number is less about how much you can send than about how much you can afford to send within the latency budget of a keystroke.

The documented figure

Mistral’s model card for Codestral 25.08 gives a context window of 128k tokens, an API name of codestral-2508, a release date of 30 July 2025, and pricing of $0.3 per million input tokens and $0.9 per million output tokens. The same card describes the model as specialising in “low-latency, high-frequency tasks such as fill-in-the-middle (FIM) and code generation”, and lists support for structured outputs, function calling, predicted outputs and prefix completion alongside the chat and FIM endpoints.

That combination — the low-latency framing and the 128k window — is the thing to reason about, because the two pull in opposite directions.

How it grew from 32k

The original Codestral, announced by Mistral in May 2024, was a 22B model documented with a 32k context window — a figure Mistral’s release announcement set explicitly against competitors offering 4k, 8k or 16k. That framing dates the post precisely: 32k was a differentiator for a code model in 2024.

The window has since grown by a factor of four. What is worth noticing is why a code completion model needed it, because the reason is not the one that drives chat model windows. A chat model wants a large window to hold conversation history and retrieved documents. A code model wants one to hold the parts of a repository that the file you are editing depends on — imports, type definitions, the interface you are implementing, the test that will run against it. That is a different shape of content, assembled by a different mechanism, and it is essentially unbounded: there is always another file that is arguably relevant.

What fill-in-the-middle does with the window

Codestral is served through a dedicated FIM endpoint as well as chat completions, and FIM is the mode that explains the model. Instead of a conversation, you send the code before the cursor and the code after it, and the model generates what belongs in between:

curl https://api.mistral.ai/v1/fim/completions \
  -H "Authorization: Bearer $MISTRAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "codestral-2508",
    "prompt": "def parse_invoice(raw: str) -> Invoice:\n    total = ",
    "suffix": "\n    return Invoice(total=total, currency=currency)\n",
    "max_tokens": 64
  }'

The suffix field is what a chat model has no way to express. An ordinary completion sees only what precedes the cursor, so it is guessing at code that has to join up with lines it cannot see. FIM gives the model both sides, which is why a model trained for it produces completions that close their brackets, match the return type on the line below, and use the variable the next line already references.

For window budgeting, the important consequence is that both halves are input. Prefix and suffix are both prompt tokens and both count against the same 128k, and in an editor integration the suffix is the half people forget to bound.

How to spend a code model’s context

128k tokens is roughly a medium-sized service’s worth of source, which makes “send the whole repository” feel newly plausible. It is usually the wrong call, for a reason that has nothing to do with the limit.

Retrieval quality dominates. A completion assembled from the four files the current file actually imports is better than one assembled from eighty files of which four are relevant, because the irrelevant seventy-six are competing for attention against the ones that matter. Filling the window is not the same as using it. The ordering matters too: content nearest the cursor has the most influence on the next token, so the file you are editing belongs closest to the completion point and the ambient context further away.

A reasonable budget for an editor integration, with every figure below an assumption about your setup rather than a documented limit:

128,000  documented window
 -2,000  the open file, both sides of the cursor
 -6,000  imported modules' signatures and type definitions
 -2,000  the nearest test file
     -64  reserved for the completion
────────
117,936  unused, deliberately

The point of that arithmetic is that a well-constructed completion request uses under a tenth of the window, and the remaining nine tenths are headroom for the cases where you genuinely need to pull in more — not a quota to fill.

What earns its place in those first ten thousand tokens is worth being opinionated about, because the ranking is fairly stable across codebases. Type definitions and function signatures for anything the current file imports are the highest value per token: they are compact, they are exactly what the model would otherwise guess at, and guessing wrong there produces a completion that calls a method with the wrong arguments. Below that, the nearest test file, which encodes intent more densely than the implementation does. Below that, sibling files in the same module, which supply naming and style conventions. Whole-file bodies of distant modules are the lowest value and the largest, which is the worst combination — they are the thing a naive “include everything nearby” strategy loads first.

Why the window is not the constraint you think

The binding constraint on an inline code completion is time, not tokens. A suggestion that arrives after the developer has typed the next line is worthless regardless of how good it was, and time to first token grows with prompt length because the whole prompt must be read before anything is generated.

So the two properties on Codestral’s model card are in tension by construction. “Low-latency, high-frequency” describes a workload of small, fast requests fired on every pause in typing. The 128k window describes a capacity you would use for a whole-file refactor or a review of a large diff — a request you make once and wait for. Those are two different products sharing one model, and the request you build should look completely different depending on which one you are doing.

Cost points the same way. At $0.3 per million input tokens, a 100,000 token completion request costs three cents in input alone. That is nothing once; fired on every keystroke pause across a team, it is the largest line in the bill, and the output — sixty tokens at $0.9 per million — is a rounding error beside it. Code completion is an input-dominated workload, which is the opposite of the usual assumption and the reason prompt construction is where the money is.

Which Codestral you are actually served

This model has been re-released more often than most, which makes the alias question sharper than it is elsewhere. There have been open 22B weights, Codestral 25.01, and Codestral 25.08, with different windows and different capabilities, and Mistral’s deprecated list already contains one of them.

Sending codestral-latest means the window and the behaviour can change without a deployment on your side. For a chat assistant that is usually tolerable. For an editor integration it is not, because a code completion model is embedded in a latency budget and a prompt construction strategy tuned to a particular version — a new release with a different window, a different tokenizer or a different FIM convention changes the shape of what you should be sending, and you will find out from a support ticket rather than a changelog.

Send the dated string, codestral-2508, and treat moving to a new one as a change you make deliberately. The related habit worth adopting is logging the model field from the response rather than the one you sent; it names what actually served the request, which is the only way to notice that an alias has moved under you. See which model version the API actually serves for how those two can differ.

One further reason this matters for Codestral specifically: the FIM endpoint’s behaviour depends on how the model was trained to consume prefix and suffix. That convention is a property of the checkpoint, so a completion strategy that works well on one version is not guaranteed to transfer, and the failure is subtle — completions that are syntactically fine and slightly wrong rather than obviously broken.