Mistral Medium 3.5: One Dense 128B Model for Chat, Code and Reasoning

Until this spring, using Mistral's models well meant choosing between product lines: Medium for general work, Magistral when you needed reasoning, Devstral for coding agents. Mistral Medium 3.5 collapses that choice. It is a single dense 128B model that Mistral describes as merging instruction following, reasoning and coding into one set of weights.

Mistral's documentation dates it to 28 April 2026. It has since become the default model in Le Chat, replaced Devstral 2 in the Vibe coding CLI and powers Mistral's new remote coding agents. That is a lot of responsibility for one checkpoint, and it changes how you should think about choosing a Mistral model.

One model where there used to be three

The practical effect of a merged model is fewer routing decisions. Instead of sending code to one model and conversation to another, you send everything to one endpoint and change a parameter. Mistral's deprecation table reflects this: Medium 3 and Medium 3.1 both name Medium 3.5 as their replacement, and so does Mistral Large 2.1.

The trade is that a generalist rarely beats a specialist at the specialist's own job. Mistral's published figures are strong on coding — 77.6% on SWE-bench Verified, which it says is ahead of Devstral 2 — and on agentic telecom tasks, with 91.4 on τ³-Telecom. Those are vendor numbers on vendor harnesses, chosen by the vendor, so the useful reading is the shape rather than the decimals: Mistral is pitching it at code and structured tool workflows. Whether it holds up as well on open-ended writing or analysis is something to test, not assume.

Reasoning effort is a per-request switch

The model card documents a reasoning_effort parameter with two values: none for a direct answer, and high for extended reasoning, which Mistral recommends for complex prompts and agentic use. The recommended sampling differs between the two:

• reasoning_effort high — temperature 0.7, top_p 0.95.
• reasoning_effort none — temperature between 0.0 and 0.7 depending on the task, top_p left at its default.

Treat high as an expense, not a quality knob. Reasoning tokens are output tokens, and on this model output is the expensive side of the bill. The sensible pattern is to default to none and switch on reasoning for the requests where you have measured that it helps. The token cost of reasoning models covers how quickly hidden output adds up.

Dense 128B, and why that matters for hosting

Most recent large open models are mixture-of-experts designs. Medium 3.5 is dense: all 128B parameters run on every token. That makes serving simpler — no expert routing, no load imbalance — but it also means compute per token is high relative to a sparse model of similar memory footprint.

Mistral says it can be self-hosted on as few as four GPUs. The example serving commands on the model card use eight-way tensor parallelism on Hopper or Blackwell hardware, so plan capacity from your own measurements rather than the minimum. There is also one trap to know about: the model card notes that the original Transformers config contained an incorrect entry that degraded long-context performance, and that GGUF conversions made from it inherit the problem. Make sure any weights or quantisations you use were built from the corrected config.

The context window is 256K tokens, with text and image input. Mistral says the vision encoder was trained from scratch to handle variable image sizes and aspect ratios.

The licence is not Apache 2.0

This is the part to read before you build on it. Mistral's earlier open releases, including Mistral Large 3 and the Ministral 3 family, are Apache 2.0. Medium 3.5 ships under a modified MIT licence with a revenue clause.

The licence text says you may not exercise its rights if the global consolidated monthly revenue of your company, or of your employer, exceeded $20 million in the preceding month. The restriction extends to derivatives and modified versions. Companies above the line can ask Mistral for a commercial licence, which it may grant or refuse, or use Mistral's hosted API instead.

For most startups and individuals that is a non-issue. For a large company, or a vendor whose customers are large companies, it decides whether self-hosting is possible at all. Open weights vs open source explains why clauses like this matter most precisely when a product succeeds.

The price went up

Mistral lists Medium 3.5 at $1.50 per million input tokens and $7.50 per million output. OpenRouter shows the same at the time of writing, with a :batch variant — the same model on an asynchronous endpoint — at half that, $0.75 and $3.75.

For comparison, Medium 3 and 3.1 listed at $0.40 and $2.00. A team migrating on Mistral's deprecation schedule pays nearly four times as much per token, before accounting for reasoning output. Whether that is a fair trade depends on whether the merged model lets you drop a separate coding or reasoning model, and whether it completes tasks in fewer attempts. The Mistral Medium 3.1 guide covers what you are migrating from.

How to evaluate it

1. Pick fifteen tasks you currently split across models — some conversational, some coding, some needing multi-step reasoning.
2. Run each through Medium 3.5 with reasoning_effort set to none, then again at high.
3. Record pass rate, total output tokens and wall-clock time for each setting.
4. Compute cost per completed task, not per token, and compare it with what you pay today across your current models combined.
5. If you plan to self-host, check the revenue clause with whoever signs your contracts before you benchmark the hardware.

If the merged model handles all three kinds of task at an acceptable rate, the simplification alone may justify the price. If it only wins on coding, a cheaper general model plus Medium 3.5 for code is the better arrangement.