What Model Version the Mistral API Actually Serves Under a Family Name

mistral-large-latest is not a model. It is a name that resolves to a dated snapshot such as mistral-large-2411, and the target changes when Mistral ships a new one. The API publishes the current mapping, which means you never have to trust a page for it — including this one.

Why the answer cannot be written down

People arrive at this question for one of three reasons, and it is worth knowing which is yours because the follow-up differs. Either something changed and you want to know whether the model did; or you are about to pin and need the id to pin to; or you are reading a benchmark and want to know what was actually measured.

In all three cases a written answer is a liability. Mistral’s naming convention encodes the release in the id — a four-digit YYMM suffix, so 2411 is November 2024 — and the alias is repointed with each release. Any page that says “the alias currently resolves to X” is accurate for a window measured in months. The mechanism below is accurate indefinitely.

The alias mapping, from the API

GET /v1/models returns one entry per model, and each dated snapshot lists the aliases that currently point at it in an aliases array. Inverting that array gives you the mapping:

curl -s https://api.mistral.ai/v1/models \
  -H "Authorization: Bearer $MISTRAL_API_KEY" \
  | jq -r '.data[] as $m
           | (($m.aliases // [])[] | . + "  ->  " + $m.id)' \
  | sort

Each row is “the name you send” on the left and “the snapshot that serves it” on the right. Run it and you have today’s answer for every family at once — large, small, codestral, embed and anything else your key can reach.

The same response carries the other two fields worth reading while you are there. max_context_length is the window for that snapshot, which is not necessarily the same as the previous one — see how the Small line’s window changed between generations for what that can do to code with a constant in it. And capabilities flags what the snapshot supports, which is how you find out that function calling or vision is or is not available without discovering it from an error.

Run it as a scheduled job rather than once by hand and you have something better than an answer: a history. Committing the output to a file on a nightly schedule means the day an alias moves shows up as a one-line diff with a date attached, which is precisely the artefact you want when somebody asks whether anything changed last Thursday.

What the response field tells you

Every chat completion response carries a top-level model field. It is the first thing to check when you are debugging, and it is worth logging on every request — but be careful about what you conclude from it.

resp = client.chat.complete(
    model="mistral-large-latest",
    messages=[{"role": "user", "content": "ping"}],
    max_tokens=1,
)
print(resp.model)

If you are calling Mistral models through somebody else’s platform rather than Mistral’s own API, the alias may be resolved by that platform rather than by Mistral, and the answer above does not necessarily apply. Ask the platform what a bare family name maps to; if it cannot tell you, send a dated id and remove the question.

When the pointer moves

A repoint is not an announcement you receive; it is a thing you notice or do not. The observable symptoms, roughly in order of how often they are what actually happened:

• Output length and formatting shift. New snapshots commonly differ in verbosity and in how readily they reach for markdown headings or bullet lists. A prompt tuned to produce three sentences starts producing five.
• Tool-calling eagerness changes. A snapshot that calls a tool where the previous one answered in prose, or the reverse, breaks a pipeline that assumed one branch. That behaviour and its causes are covered in when Mistral declines to call a tool.
• A seeded result stops reproducing. If a random_seed that reliably produced one answer suddenly does not, check the snapshot before you conclude the seed is broken.
• Cost per request moves without traffic moving. Different pricing on the new snapshot, or simply longer answers. Either way the token counts in your logs show it.

None of these produce an error, which is precisely the problem: an upgrade you did not choose arrives as a quality report from a user rather than as an alert.

The old snapshot does not usually vanish at the moment the alias moves. Repointing an alias and retiring the model it used to point at are two separate events, normally separated by months, which is what makes recovery possible: if a repoint breaks you, sending the previous dated id restores the previous behaviour immediately while you work out what changed. That escape route only exists if you know which id you were on before, which is the argument for logging the model string on every request even when you have no intention of pinning.

What to do with the answer

Having found the snapshot, there are two reasonable positions and you should hold one of them deliberately.

Stay on the alias if you are prototyping, if you want improvements as they land, and if a behaviour change costs you an afternoon rather than an incident. This is a legitimate choice and it is why the aliases exist. It is also the right choice for internal tooling with a human in the loop, where a slightly different answer is noticed and corrected rather than propagated.

A useful middle position, if you cannot decide: pin production and leave a scheduled evaluation job on the alias. The job runs your prompt suite nightly against -latest and records the model string it was served along with the results. When the alias moves, you have a before-and-after on your own tasks within a day, produced by a machine rather than by a customer complaint, and the decision to move the production pin is made from evidence. That is a small amount of infrastructure that converts the whole question from a judgement call into a number.

Otherwise send the dated id, and add the retirement check that tells you before it is withdrawn — the procedure is in pinning a dated Mistral model version. Whichever you choose, log the model string on every request. The question “did the model change on the day the complaints started?” is answerable in five seconds if you logged it and essentially unanswerable if you did not.