The trillion-parameter model you can finally download: what Mistral Large 4's open weights mean

On 29 October 2026, Mistral released the weights of Large 4. The model has an official nickname, "Le Chonk," and it earns it: roughly 1 trillion total parameters, about 49 billion active per token (52 billion counting embeddings and output layers), a 1-million-token context window, and native text-and-image input. It first appeared on 6 October as an API-only preview, with weights promised "by the end of the month." Three weeks later, the promise was kept: the weights are on Hugging Face, free to download, self-host, and fine-tune.

Why should vibe coders care more about this than about the usual "new model" headline? Because it changes who gets to hold a frontier-class model. For months, the trade-off has been stark: closed models are stronger but require sending your code, data, and prompts to someone else's servers; open-weight models are yours to control but usually a step behind. Large 4's open weights push that trade-off to a new point — a model Mistral claims leads open weights in coding and cyber defence can now run on infrastructure you control.

What was actually released

Start with the architecture, because the "1 trillion" figure misleads on its own. Large 4 is a mixture-of-experts model: the total is about 1.05 trillion parameters, but each token only routes through a small subset of experts, roughly 49 billion active parameters, plus a 1.6-billion-parameter vision encoder for image understanding. The 1-million-token context means it can take in very large codebases, document sets, or log files in a single request. Reasoning effort is adjustable per request — low, medium, or high — which matters for balancing cost against depth.

The released checkpoint is not a straight copy of the 6 October preview. Mistral says it received three more weeks of reinforcement learning and customer testing. According to reporting of Mistral's claims, its Terminal-Bench 4.0 score rose from 28.3% at preview to 41%; on Cognition's private FrontierCode benchmark, Mistral reports 19.7% and calls it the best open-weight result; on Artificial Analysis's Coding Agent Index, Mistral reports around 48%, effectively tied with China's GLM-5.3 while using 47% fewer tokens per task on average. Every one of those numbers comes from Mistral or its partners. None has been independently reproduced, and that qualifier should stay attached to each figure whenever you repeat it.

Two practical facts complete the picture. First, the weights ship as 54 FP8 safetensors files, with an official vLLM serving recipe spanning 8 GPUs; a 4-bit NVFP4 quantized variant is also available, which Mistral says matches performance on four Nvidia B200 or B300 GPUs. Second, Mistral's own API remains on sale at $0.70 per million input tokens, $0.07 per million cached input tokens, and $2.10 per million output tokens. Downloading weights and calling the API are both live options. Which one fits depends on whether you have hardware and operations capacity, not on being forced into one path.

The licence: open, with one carve-out

Large 4 ships under the Mistral Ecosystem Open-Weight License, described as a modified MIT licence. In plain terms: you may use, modify, fine-tune, and build commercial products on it for free. There is one exception that deserves to be stated separately: if you run a Model-as-a-Service business — selling access to the model itself as a service — you need a separate commercial licence from Mistral first.

For most vibe coders, that exception will never bite. Writing code with the model, shipping products built on it, and running it on your own servers are all outside it. But if your business idea is precisely "wrap this model in an API and resell access," read the licence before you build. Many past "open model" disputes started exactly at this boundary: people assumed MIT meant unrestricted use, then discovered the line at reselling the model itself. Large 4 draws that line in the open, which is more trustworthy than a vague "open source" slogan.

One more caveat: open weights are not unconditional use. Mistral acknowledges that during the preview it saw "a potential for uplift to conduct real attacks," and a more aggressive penetration-testing variant stays restricted to vetted partners rather than being published. Mistral also says a full technical report is "coming soon," so there is not yet a complete document to check architecture and evaluation claims against. Both points belong in any serious adoption decision: downloadable weights are not the same as complete information.

How good is it at coding, really

For vibe coders, the useful question is not parameter count but performance on real programming work. That needs two layers. The first is Mistral's own numbers: Terminal-Bench 4.0 up from 28.3% to 41% would be a visible gain from three weeks of reinforcement learning, if it holds up. The DeepSWE v1.1 figure of 61.7% and SWE-Atlas-QnA figure of 59.4% come from the 6 October preview, and reporting is not fully consistent about whether they carry over to the released checkpoint — so do not mix preview and release numbers when you compare models.

The second layer is third-party perspective. Artificial Analysis's Intelligence Index scores Large 4 at 26, calling it the highest among Western open-weight models, but still about 6 points behind the leading Chinese open-weight models, with the gap concentrated in coding and agentic knowledge work. That framing is honest and useful: Large 4 is "best Western open-weight option," not "best open-weight model overall." If you value a European vendor, European datacenters, and self-deployment, it is currently the weightiest choice in that category. If you only care about the absolute benchmark high score, it is not the only answer.

Cyber defence is Mistral's other headline. The company reports 51% on Artificial Analysis's Cyber Index and says the model refused 96.6% of malicious cyber requests in its own tests; on a reproduce-and-patch test for real vulnerabilities it reports 82%, and on Cybench, 40 security-competition challenges, it reports 93%. Again, vendor and partner numbers. The underlying argument is worth engaging with: defensive work often starts by proving a flaw is real, and refusal mechanisms in some closed models block exactly that legitimate work. Open weights let defenders run that work under their own policies. The flip side is equally direct: once weights are public they cannot be recalled, and a determined user can try to fine-tune the refusals away. Openness and safety pull in opposite directions here, and Large 4 makes that tension unusually visible.

Who should take it seriously, and who should wait

Three groups should take it seriously. First, anyone with hard requirements to keep code and data in-house — finance, healthcare, government, law, or any client contract that forbids sending data to a third-party model service. For them, open weights are not about saving money; they are a precondition for compliance. Second, teams that already run GPU infrastructure or already serve open models with vLLM or SGLang: Large 4 slots into existing pipelines, and the marginal cost is hardware and operations rather than a rebuild. Third, people doing security, vulnerability research, and code auditing, where "reproducible, verifiable, runnable offline" is a core requirement rather than a nice-to-have.

Three groups should wait. First, solo developers with only a laptop and no server budget: this is not a laptop model, and the official 8-GPU recipe or 4-Blackwell-card quantized setup is far beyond personal hardware. For them, the API or a community-hosted endpoint is the realistic first step. Second, anyone who wants "it just works, no operations": downloading weights is step one, and deployment, quantization, monitoring, updates, and incident handling are all yours afterwards — a different workload from calling a managed API. Third, anyone waiting for the full technical report: until Mistral publishes it, detailed judgements about training data and evaluation methods can only be provisional.

My judgement

My judgement is that the real significance of Large 4's open weights is not whether it is "the strongest open model." It is that "frontier capability plus self-deployment" finally has a complete answer from a European vendor. Until now, that combination usually meant accepting a weaker model or accepting a model from a Chinese vendor; now there is a third option, with discussable results in the two areas vibe coders care about most — coding and cyber defence.

Keep expectations in proportion, though. Vendor benchmarks are not independent reproductions, preview and release numbers must not be mixed, the Model-as-a-Service licence exception needs checking before you build a resale business, and the full technical report has not landed yet. For most vibe coders, the sensible first step is not buying GPUs. It is running a few of your own real tasks through Mistral's API or a community endpoint first: refactor a piece of legacy code, write tests for a repository, reproduce a known vulnerability and verify the patch. Do those tasks, then decide whether the model earns a place in your toolbox. The weights can be downloaded by anyone. The judgement still has to be your own.

The real cost of self-hosting

"Weights are free to download" easily misleads people into thinking "they are free to run," and that is the most common mistake in adoption decisions. The bill has at least four lines. First, hardware: the official FP8 recipe needs 8 GPUs, the NVFP4 route needs 4 Blackwell cards — either way, buying or renting is not a small number, and that is only the inference bill; fine-tuning costs extra. Second, power and cooling: a trillion-parameter model, even sparsely activated, is a datacenter-class power and cooling problem, not something to tuck into an office corner. Third, operations headcount: model updates, quantization configuration, security patches, troubleshooting, and usage monitoring are all handled by the vendor when you call an API; self-hosting brings them all back in-house. Fourth, opportunity cost: time your team spends on deployment and tuning is time not spent on the product itself.

A more honest comparison puts "three months of total self-hosting cost for Large 4" next to "three months of API bills plus data-compliance risk." The first is heavy on fixed costs and headcount; the second is heavy on per-call price and compliance uncertainty. For high, stable-volume teams, self-hosting marginal costs thin out with usage; for low or spiky-volume teams, the API is usually cheaper. That conclusion has nothing to do with model quality and everything to do with the shape of your usage curve. Many teams compare only per-call prices, forget operations headcount, and discover after deployment that the total bill is upside down.

One cost is routinely forgotten: evaluation. Switching models is not changing one line of configuration. You must run benchmarks on your own tasks, do regression testing, check output formats for changes, and verify long-context behavior has not regressed. That work is required for any model switch, Large 4 included. If your team does not even have an evaluation baseline for its current model, the gains from a stronger model may be eaten by missing evaluation — you simply will not know whether things got better or worse.

What the community is already doing

The community's first-week response is itself news. According to reporting, Hugging Face launch day brought support in Transformers, vLLM, and llama.cpp, the community produced GGUF files for local inference tools, Microsoft Foundry became one of the first clouds to carry the model, and Nvidia offered a NIM container. That tells you something important: Large 4 is not a "Mistral-platform-only" model; its ecosystem position was open from day one. For adoption decisions, that matters: a model's long-term value depends heavily on how many people adapt it, fix bugs, and write tutorials — not just on launch-day benchmark scores.

But community enthusiasm needs a cool head. Launch-week adaptation is not a long-term maintenance commitment: community GGUF builds, third-party quantized versions, and wrapper tools vary in quality, and production use requires verifying each one rather than trusting it because "the community made it." Quantization deserves particular care: precision loss that looks invisible in general Q&A can amplify in precision-sensitive tasks like code generation and long-context reasoning. Before production, compare the original and quantized outputs on your own representative tasks rather than trusting a release note's "same performance" claim.

So what should a vibe coder actually do now? I suggest three steps. First, validate quickly through the API: pick three tasks you have genuinely faced, run them, record output quality and cost, and compare with your current tools. Second, wait two to four weeks for the full technical report and community feedback to settle, watching for problems worth worrying about — systematic weaknesses on particular tasks, licence interpretation disputes, deployment pitfalls. Third, if the first two steps pass, deploy at small scale for validation: one non-critical scenario, two weeks, confirming operations cost and stability before expanding. After those three steps, your judgement is no longer "I heard it is strong" but "it demonstrably works on my tasks." That is what an adoption decision should look like.