Skip to content
NLEN
Illustration: Mistral Large 4 (Le Chonk) goes open weights: what builders need to know

Mistral Large 4 (Le Chonk) goes open weights: what builders need to know

By Ivo Donker · — with AI assistance (DeepSeek V4.1 Flash)

Mistral has released the weights of an improved Mistral Large 4, nicknamed 'Le Chonk'. That happened on 29 October 2026, according to the Hugging Face blog. Earlier in October, Mistral Large 4 was already in public preview; since then Mistral has applied roughly three more weeks of additional reinforcement learning based on feedback. The stated focus of this release is agentic coding and defensive cybersecurity. Mistral summarises the positioning on X as 'Built to build', 'Built to defend' and 'Built for sovereignty'.

For builders the core is simple: you can host the model yourself or use it through an API, with a per-token price where output is more expensive than input. But the leaderboard claims, the active-parameter counts and the licence demand precision. Below is what was actually released, how to read the numbers and what you should test yourself before putting this model into a production path. Where relevant we link to the comparison between open source and open-weights models, because those two are often conflated in discussions.

What Mistral is releasing

This concerns the weights of Mistral Large 4, so not just an API endpoint. You can download the model from Hugging Face, in official FP8 and NVFP4 variants, and run it yourself with vLLM (which Mistral recommends) or SGLang. There is also support in Transformers and llama.cpp. The model is available via Mistral Studio, the Mistral API and OpenRouter, and additionally via Microsoft Foundry and NVIDIA-hosted endpoints and NIM. A full technical report is, according to Mistral, 'coming soon'.

The model is listed on Hugging Face as mistralai/Mistral-Large-4-1T-A52B. That name already says a lot about the architecture: 1T refers to the total number of parameters and A52B to the number of active parameters. That is exactly where a nuance sits that you need to read carefully, because marketing copy often summarises the active count too crudely.

If you want to choose a model for code, it is best to compare the open-weights options against closed alternatives on the same tasks. To do that, it helps to have your criteria sharp first; the guide on choosing models for code helps with that. For agentic workflows, which this model explicitly targets, the same applies, but with extra emphasis on tool calls and completing multi-step tasks; see models for agents for that.

Size and architecture: 1 trillion total, 49 billion active

According to the technical model card, this is about 1 trillion total parameters, in a Mixture-of-Experts setup with 49 billion active parameters per token. Including embeddings and output layers, that comes to 52 billion. There are 128 routed experts, 4 of which are active per token, plus 1 shared expert. Artificial Analysis cites 1.05 trillion total and 52 billion active. Those two figures are not contradictory, but they measure slightly different things: one is the total parameter count, the other the active count with a different demarcation.

The practical lesson: if someone says this is a '52B model', that is only correct if you count embeddings and output layers. If you say '49 billion active per token', you are on the definition from the model card. Both are usable, but you should not use them interchangeably as if they were the same number. For your calculations on memory and throughput, that makes a difference: with MoE models the active portion largely determines the compute cost per token, while the total number of parameters determines how much weight you have to store and how you lay out your hardware.

The model card also mentions a context window of 1 million tokens. The model is natively multimodal for input: text and image in, text out. It is natively fluent in more than 160 languages, including all official EU languages. It was trained from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral's own datacenters in Europe, and it is served on the Mistral API as mistral-large-4.

For self-hosting that means concretely: you plan storage and memory bandwidth for a model of roughly 1 trillion parameters, while your compute budget per token sits closer to a much smaller active portion. The FP8 and NVFP4 variants exist precisely to make that feasible. Which variant you choose depends on your hardware and on your tolerance for quality loss; that is something you have to measure yourself on your tasks, not something you can derive from a leaderboard.

Leaderboards: best open model outside China

Artificial Analysis calls Mistral Large 4 'narrowly' the number 1 open-weights model developed outside China. The score is 26 on the Artificial Analysis Intelligence Index v5, one point higher than the Preview's 25. That puts it 1 point ahead of the leading open-weights model developed in the United States, Muse Spark Open (25). Important: the leading open-weights models from China, DeepSeek V4.1 Flash 1017 and GLM-5.3, score 6 points higher on that same index. So this is not the number 1 open-weights model worldwide.

That qualifier is not a formality. If you choose a model for an agentic pipeline, a difference of 6 points on an index can be exactly the difference between a task that gets completed reliably and a task where you have to intervene manually. At the same time, an index score by itself says little about your specific workload. Use such figures as a starting point for a shortlist, not as the final answer. The page on pricing models per token explained is useful here, because higher quality on an index can still work out more expensive once you generate a lot of output tokens.

Mistral itself claims a number 1 position on a different list: according to Mistral, Mistral Large 4 ranks number 1 among open models on Cognition's private FrontierCode 2.0 benchmark, with a score of 19.7 percent. That claim is therefore specific: it concerns open models and that one benchmark, and the source is Cognition as reported by Mistral. Such claims are usable if you read them exactly that way, and misleading if you summarise them as 'the best open model'.

FrontierCode: two measurements, two numbers

This is where misquoting happens most often. There are two different measurements of FrontierCode 2.0 in circulation, and you must not swap them.

On the one hand there is Mistral's figure: 19.7 percent on FrontierCode 2.0, reported by Mistral, based on Cognition's private benchmark that measures end-to-end code quality and whether a repository maintainer would merge the agent's change. On the other hand there is Artificial Analysis' own measurement: 15 percent for Mistral Large 4, versus 29 percent for DeepSeek V4.1 Flash 1017 and 22 percent for GLM-5.3. Artificial Analysis cites that difference as a reason Mistral trails those models.

Those are two separate figures with two separate sources and two separate measurement setups. The 19.7 percent is not the same as the 15 percent, and you cannot average them or present them as confirmation of each other. If you refer to FrontierCode in an internal evaluation, state which measurement you mean and who carried it out. Otherwise you get discussions in which two parties both appear to be right while they are measuring different things. This is exactly the type of difference that also plays a role when assessing quality versus cost: the same model name can tell two different stories in two reports.

For your own decision this means you should not sail on a single benchmark figure, but on a set of tasks that resemble what your users do. Especially with code and agents, where the environment, the tooling and the evaluation criteria strongly determine the outcome, your own yardstick is worth more than a borrowed leaderboard.

Licence: MEOW instead of ordinary MIT

The licence is the Mistral Ecosystem Open-Weight license, abbreviated MEOW. It is a modified MIT licence. You may freely use, modify, fine-tune and commercialise the model, with one condition: businesses operating a Model-as-a-Service offering must obtain a separate commercial licence from Mistral before using the model commercially. So it is not ordinary MIT, and not a pure MIT licence either.

That single exception is exactly where many teams go wrong. As long as you use the model in your own product, for example as part of an application or internal tooling, you fall under the general 'free to use' part. As soon as you offer the model as a service to others, that changes. So do not read the licence as 'MIT under another name', but as a licence with a specific commercial exception for model-as-a-service. More background on what is and is not allowed with open models can be found in the guide on licences of open models: what you may do commercially.

In practice this means that before launching a hosted inference service you must check whether your offering falls under that exception. Do that before you publish your pricing model, because a licence problem afterwards is more expensive than a short conversation beforehand. It is also sensible to read the licence text itself and not just the summaries circulating online, because the demarcation of 'Model-as-a-Service' is decisive for your situation.

Price via the API

The prices via the API are: $0.70 per 1 million input tokens, $0.07 per 1 million cached input tokens and $2.10 per 1 million output tokens. Mistral cites those figures in the blog, and Artificial Analysis reports the same amounts. The output price is three times the input price. The cached rate is one tenth of the ordinary input rate.

For agentic workloads the ratio between input and output matters. Agents often send a lot of context and generate relatively few tokens per step, but they do take many steps. In such cases the input side adds up and caching helps. It therefore pays to design your prompt structure so that the fixed part of the context is cacheable, so that a larger share of your traffic is billed at the cached rate. The exact saving depends on your cache layout and your traffic patterns; that is something you have to measure, not assume.

With self-hosting, the token prices disappear, but costs for hardware, power, cooling and management take their place. So do not calculate only with the API prices, but compare them with your own cost per token for the FP8 or NVFP4 variant on your hardware. For a first estimate you can use the API prices as a reference; for the final choice you want to know your own load.

Reasoning levels and self-hosting

The model has three reasoning levels: low, medium and high, with high as the default. The low level replaces the former 'None' mode. According to the Hugging Face blog, reasoning cannot be fully disabled. That is relevant if you care about latency or if you want to reduce cost per request: you cannot leave the reasoning work out entirely, but you can lower it.

If you host it yourself, you can choose vLLM, which Mistral recommends, or SGLang, with support in Transformers and llama.cpp. The official variants are FP8 and NVFP4. Which of the two you take depends on your hardware and on how much quality loss you accept. Test that on your own tasks, with your own prompts, and not on a general set that has little to do with your product.

For agentic applications it is sensible to choose the reasoning level per task type. A classification step often does fine with low, while a planning step can benefit from high. Because the level is configurable per call, you can combine different levels in your orchestration. Measure both quality and latency, because a higher level generally costs more tokens and therefore more time and money.

Defensive cybersecurity and guardrails

Mistral positions this model defensively in the area of cybersecurity. According to Mistral, there are built-in guardrails intended to distinguish defensive tasks from malicious or offensive cyber activities. Mistral says it handles legitimate defensive tasks, such as reproducing and patching vulnerabilities, without unnecessary refusals. Mistral has monitored cyber-related live traffic since the preview and says it sees potential for real attacks in it; that is why it is modifying the guardrails and will keep updating them.

There is also a specialised cyber variant for penetration testing and red-teaming, but it is only in preview for selected enterprise design partners, such as Orange Cyberdefense, under contractual safeguards and restricted to systems they own or for which they have authorisation. That is a demarcated, controlled route, not something that is generally available.

All of this consists of vendor claims; label them as such in your own documentation. Guardrails are also no substitute for your own controls. If you put this model into a security workflow, human review remains necessary, certainly when reproducing vulnerabilities and when approving patches. For choosing models in this domain, the guide on choosing models for cybersecurity and code audits is a usable starting point, and for the broader context around this topic you can turn to the background piece on AI and cybersecurity.

Mistral additionally cites a sovereignty argument: organisations can inspect, customise and run the model on their own infrastructure without depending on Mistral's API, and it was trained from scratch in Europe. That is a consideration separate from the benchmark figures, but one that weighs heavily in some organisations when choosing between a hosted endpoint and their own deployment.

What this means for builders

If you are building an agentic code assistant, you get a model here in the class of roughly 1 trillion parameters with public weights and a licence that permits commercial use except for model-as-a-service. That gives you the option to fine-tune on your own codebase and to run the model in your own environment if needed. At the same time, a model of roughly 1 trillion total parameters demands serious hardware, even though the active portion per token is 49 billion (52 billion including embeddings and output layers).

So start with the question of whether you want to host it yourself or work via the API. For a prototype the API is usually the quickest start, at $0.70 per 1 million input tokens, $0.07 per 1 million cached input tokens and $2.10 per 1 million output tokens. For a situation in which your data may not leave the building, or in which you want full control over the weights, self-hosting is the route, with the caveat that you are then also responsible for updates and for evaluating the FP8 or NVFP4 variant on your tasks.

Do not forget to put the leaderboards in perspective. According to Artificial Analysis this is the best open-weights model developed outside China, with a score of 26 on the Intelligence Index v5, and Chinese open models score 6 points higher. According to Mistral it ranks number 1 among open models on Cognition's FrontierCode 2.0 with 19.7 percent, while Artificial Analysis' own measurement is 15 percent versus 29 percent for DeepSeek V4.1 Flash 1017 and 22 percent for GLM-5.3. Those are two different measurements that you must treat separately.

The main gain for you is probably not in the headline of a leaderboard, but in the combination of open weights, a million tokens of context, fluency in more than 160 languages and the ability to choose the reasoning level and hosting yourself. Test it on your own tasks, look at latency and cost per completed task, and read the MEOW licence before you launch a service.

Checks for your own setup

Anyone who runs through these points before something goes into production avoids the most common mistakes with releases like this: reading a licence incorrectly, mixing up two benchmark figures and adopting an active-parameter count without the right demarcation. The rest is simply measuring on your own work.

Checked on 2026-10-30.

This article was compiled with AI assistance and editorially reviewed; sources are listed below.

Sources