Mistral Large 4 Open Weights Are Live: A 1-Trillion-Parameter AI Built to Find and Fix Flaws

Mistral Large 4, Nicknamed Le Chonk, Brings Open Weights to Vulnerability Research

Mistral has released Mistral Large 4, nicknamed Le Chonk, as an open-weights model focused on vulnerability research and related security work, and the release has quickly become a talking point for defenders, researchers, builders, and anyone following the debate about open versus closed artificial intelligence. The open weights were released on October 29, 2026, on Hugging Face, following a preview on October 6. That short gap between preview and full release matters because it gave partners and early testers a chance to try the model, report findings, and shape expectations before the wider community could download and run it for themselves.

The headline idea behind Large 4 is not simply that it is large, although its scale is striking. It is that a model built for finding, reproducing, and patching vulnerabilities is now available as open weights, subject to a licence that permits commercial use with an important condition for hosted-model-service providers. That combination — powerful security capability plus broad availability — is exactly why the release is both exciting and sensitive. Defenders hope it will help them find flaws faster and fix them before attackers exploit them. Critics worry that the same capability could help attackers if it is misused. Mistral itself appears to recognise that tension, and the release comes with safety discussion, restricted handling of a specialised cyber variant, and partner testing that deserves careful reading rather than a quick verdict.

This article explains what Large 4 is, what its reported benchmarks do and do not prove, how its licence and access routes work, how it compares with a restricted frontier model such as Google Gemini 4 Carbon, and what practical guidance applies to anyone considering it. Every benchmark figure in this article is vendor-reported or partner-reported, and is labelled as such. That caveat is not a footnote; it is central to understanding the release, because vendor benchmarks are useful signals but they are not independent audits, and they are measured under conditions chosen by the vendor or its partners.

What Mistral Large 4 Is

Mistral Large 4 is described as a model with around one trillion total parameters, with around 49-52B active per token. In plain language, the total parameter count describes the overall size of the model, while the active-per-token figure describes how much of that model is actually used for each token it processes. That distinction is important for practical deployment: a very large model can still be efficient to run if only a portion is active at a time, and efficiency affects cost, speed, and what hardware is needed.

The model is also described as natively multimodal, with a 1M-token context. A long context means the model can take in a very large amount of input at once — for vulnerability work, that could mean large codebases, lengthy logs, extensive documentation, or a long investigation trail — without losing the thread as quickly as a model with a short context would. Multimodal capability means the model is designed to work with more than plain text alone, although the details supplied for this article focus on its security and coding strengths rather than on a full tour of every modality. For security teams, the combination of long context and code-focused ability is the core appeal: real vulnerabilities rarely live in a single short snippet, and understanding them often requires tracing data and logic across many files.

The nickname Le Chonk, used in the release discussion, captures the scale in a memorable way, but it should not distract from the serious purpose Mistral assigns to the model. This is not presented as a general chatbot first and a security tool second. It is presented as a model whose strengths are in vulnerability research, coding, and agentic work — work where the model does not merely answer a question but carries out steps, uses tools, tests hypotheses, and iterates toward a result. That agentic framing is where both the promise and the risk live, because an agent that can reproduce a vulnerability and propose a patch is far more useful than a model that can only describe a vulnerability in theory.

Open Weights, Licence, and Who Can Use It

Open weights mean that the trained model weights are made available for download and use, rather than being accessible only through a vendor-controlled application programming interface. For developers and researchers, that difference is profound. With open weights, a team can run the model on its own infrastructure, inspect its behaviour more directly, fine-tune it for a specific task, integrate it into private workflows, and avoid sending sensitive code to a third-party service. For organisations handling private codebases, security investigations, or regulated data, that control can be decisive.

Large 4 is released under a modified MIT-style licence. Commercial use is allowed under that licence, which is an important signal for companies that want to build products or services around the model without seeking a separate permission for ordinary commercial use. There is, however, a key condition: hosted-model-service providers need a separate commercial licence. That condition draws a line between using the model in a product and offering the model itself as a hosted service to others. Builders who plan to offer Large 4 as a hosted model service should therefore check the licence terms carefully and seek the separate licence if their use falls in that category, rather than assuming the general commercial permission covers every business model.

The licence discussion also illustrates why open does not mean unrestricted in every sense. Open weights can coexist with licence conditions, safety policies, and restricted variants. Mistral keeping a specialised cyber variant restricted to vetted partners is an example of that nuance. The main model is broadly available, while a more specialised version is handled more tightly. Readers should not collapse those two things into a single claim that everything Mistral built is either fully open or fully closed; the release is deliberately layered.

How to Access and Run Large 4

Large 4 is available through a range of routes, which reflects how different users want to work with a model of this size. It is available via the Mistral API and Mistral Studio, via OpenRouter, via Hugging Face, via Microsoft Foundry, and via Nvidia NIM. For teams that prefer to self-host, it is also described as available for self-hosting through vLLM and SGLang, which are popular serving frameworks for large language models. That breadth of access means a small research team, a large enterprise, and an independent developer can each approach the model in a way that fits their infrastructure, budget, and privacy requirements.

One report describes the model as running on as few as four Nvidia B200 or B300 GPUs. That figure, if accurate for a given configuration, is significant because it puts self-hosting within reach of well-resourced teams rather than only the largest cloud providers. It does not mean every user needs that hardware, and it does not mean every deployment will run well on that minimum. Performance depends on context length, batch size, quantisation, serving framework settings, and the workload itself. Still, the reported hardware floor helps explain why the release feels practical rather than purely theoretical: a team with serious GPU infrastructure can realistically consider running Large 4 itself.

For users who prefer an API rather than self-hosting, pricing reported in one report is approximately $0.70 input and $2.10 output per million tokens. API pricing matters for budgeting security work, because vulnerability research can involve very long inputs — entire repositories, logs, and test outputs — and long outputs when the model writes patches, explanations, and test cases. A team should therefore estimate costs based on its actual token use, not on a single example, and should compare API costs with self-hosting costs including hardware, electricity, engineering time, and maintenance.

Benchmarks: What Is Reported, With Caveats

Benchmarks are the most eye-catching part of the Large 4 announcement, and they are also the part that requires the most careful reading. All of the benchmark figures in this article are vendor-reported or partner-reported. That means they come from Mistral or its partners, measured under their conditions, and they have not been independently reproduced here. They are useful for understanding what Mistral claims the model can do, but they should not be treated as neutral, final proof.

The reported security benchmarks include 51% on the Artificial Analysis Cyber Index, 79% on CyberGym-E2E, 82% on a vulnerability reproduce-and-patch test, and 93% on Cybench. Taken together, those figures are presented as evidence that Large 4 is strong across different kinds of security evaluation: broad cyber capability, end-to-end gym-style tasks, the practical job of reproducing a vulnerability and then patching it, and a benchmark suite focused on cybersecurity tasks. The reproduce-and-patch figure is especially relevant to defenders, because finding a flaw is only half the job; the value lies in fixing it reliably without breaking other functionality.

Coding and agentic benchmarks reported include 19.7% on FrontierCode 2.0, described as number one among open models, 41% on Terminal-Bench 4.0, up from 28% for the preview, and 48% on the Coding Agent Index, tied with GLM-5.3 while using 47% fewer tokens. The Terminal-Bench improvement from preview to release is notable because it suggests the model improved meaningfully in the short period between preview and release, at least on that measure. The Coding Agent Index result, combined with the token-efficiency claim, suggests not only capability but also economy: achieving a comparable score while using far fewer tokens would lower cost and latency for agentic coding work, if the result holds in real deployments.

Other reported benchmarks broaden the picture beyond security and coding. They include 73.3% on Finch and 84.5% on BrowseComp. Those figures suggest the model is not a narrow specialist that collapses outside its home domain, although readers should still ask what each benchmark actually measures and how closely it matches their own tasks. A benchmark score is a proxy, not a guarantee, and a high score on a browsing or finance-related benchmark does not automatically mean the model will perform equally well on a specific internal workflow.

Benchmark Results at a Glance

The table is a summary of claims, not a league table verified by this article. Benchmarks differ in difficulty, scope, and scoring, so a high percentage on one benchmark and a lower percentage on another does not mean the model is inconsistent; it means the tasks are different. Readers comparing models should compare the same benchmark across models, under comparable conditions, and should look for independent reproductions where available.

Safety Results and the Uplift Concern

Safety figures reported for Large 4 include 96.6% average refusal of malicious requests across JailbreakBench, StrongREJECT, and AgentHarm, and 97.1% on the B3 Agent Security Benchmark. Those figures are presented as evidence that the model refuses clearly malicious requests at a high rate and behaves safely in agentic security evaluations. Refusal rates are important, but they are also limited: they measure how often a model refuses in a test set, not how it behaves in every real-world conversation, and determined attackers often try to bypass refusals through indirect prompts, multi-step conversations, or by using a model in a different context from the test.

The more nuanced safety point in the release discussion is that Mistral says live-traffic monitoring showed potential uplift for real attacks, and that Mistral is tightening guardrails in response. Uplift, in this context, means the model could help a real attacker carry out an attack more effectively than they could without it. That admission is significant because it moves the conversation beyond test-set refusal rates to observed behaviour in live use. It also explains why Mistral is tightening guardrails: a model can refuse most malicious requests in a benchmark and still raise risk if the requests it does answer, or the help it provides in borderline cases, materially assist an attacker.

Mistral keeping a specialised cyber variant restricted to vetted partners is part of the same safety posture. By limiting the most specialised version to vetted partners, Mistral aims to give trusted defenders access to advanced capability while reducing the chance that the most potent version circulates freely. Vetted partners named in the discussion include organisations such as Orange Cyberdefense and others in the partner-testing group. That approach will not satisfy everyone: open-access advocates may argue that restriction undermines openness, while safety advocates may argue that even the main open model is too capable to release broadly. Both concerns deserve to be heard, and neither is resolved by a single release decision.

Partners Testing Large 4

Partners described as testing Large 4 include CrowdStrike, Cloudflare, Cisco, Fortinet, Elastic, Zscaler, Rubrik, Booz Allen, and ENISA, alongside Orange Cyberdefense in the specialised-variant context. That list spans endpoint security, cloud and network security, data and observability, and public-sector and advisory work, which suggests Mistral is seeking feedback from across the security ecosystem rather than from a single niche. Partner testing matters because security vendors and agencies bring real-world codebases, threat models, and operational constraints that a laboratory benchmark cannot fully capture.

For readers, the partner list should be read as context, not as endorsement. A partner testing a model is not the same as a partner deploying it in production for all customers, and testing can surface limitations as well as strengths. It is also worth noting that partners have their own incentives: a security vendor may be interested in a model that helps its own products, while a public agency may be interested in understanding risk and resilience. The diversity of the list is therefore useful, but it does not replace independent evaluation by a team with no commercial stake in the outcome.

Over time, the most informative evidence will come from how these partners and independent researchers actually use Large 4: which vulnerabilities it finds that humans missed, which patches it proposes that pass rigorous testing, where it hallucinates or introduces new flaws, and how often its suggestions require human correction. Until that operational evidence accumulates, benchmark figures should be treated as a starting point for investigation, not as a conclusion.

Contrast: Gemini 4 Carbon and the Closed Frontier

The contrast most often drawn with Large 4 is Google Gemini 4 Carbon, released on October 28, with restricted Fairwind access and API pricing reported at $2 input and $10 output per million tokens. The contrast is instructive because the two models represent different philosophies. Large 4 is open weights with broad access routes and a licence permitting commercial use, subject to the hosted-service condition. Gemini 4 Carbon is described as restricted, with access through a controlled route and substantially higher reported API pricing. That pricing difference alone changes who can experiment, how much experimentation costs, and how quickly a small team can iterate.

Restricted access has its own logic. A vendor that keeps a powerful security-capable model behind a vetted route can monitor use more closely, revoke access if misuse is detected, update guardrails centrally, and limit the circulation of weights that could be fine-tuned to remove safeguards. For a model with potential uplift for real attacks, those controls are not trivial. They give the vendor a lever that open weights, by design, do not provide: once weights are downloaded, the vendor cannot un-release them or force every user to adopt a new safeguard.

Open access has a different logic. Defenders can run the model privately on sensitive code, researchers can study it without permission gates, smaller companies can build without paying premium API prices, and the broader community can find flaws, improve safeguards, and develop defensive tools faster. Open weights also allow offline and air-gapped use, which matters for organisations that cannot send code to an external service. The risk is that attackers gain the same benefits, including the ability to fine-tune the model, run it without monitoring, and experiment freely to bypass safeguards.

Neither philosophy eliminates risk; they distribute risk differently. Closed access concentrates control with the vendor but creates dependency, cost barriers, and a single point of failure for access decisions. Open access distributes capability widely, which can accelerate defence but also removes the vendor control lever. The Large 4 release, with its layered approach — open main model, licence condition for hosted services, tightening guardrails, and restricted specialised variant — can be read as an attempt to balance those trade-offs rather than to choose one extreme.

Large 4 Versus Gemini 4 Carbon Versus Closed Frontier Models

The table should not be read as a ranking. It compares access, pricing, and control models, not a head-to-head capability score, because the details supplied do not include a directly comparable, independently verified benchmark set across all three columns. A buyer or researcher choosing between these routes should weigh capability for their specific task, cost at their actual token volume, privacy requirements, and how much control they need over deployment.

What Open Weights Mean for Defenders Versus Attackers

For defenders, open weights offer speed and privacy. A security team can test Large 4 against its own codebase without exposing that code externally, can integrate the model into internal triage pipelines, can fine-tune it on internal patterns, and can run it in environments where external API calls are restricted. That can shorten the time between discovering a potential flaw and confirming whether it is real, and between confirming a flaw and producing a patch that passes tests. In incident response, where hours matter, that speed can be valuable.

For defenders, open weights also offer transparency and community improvement. Researchers can probe the model for weaknesses, publish evaluations, share fine-tunes for defensive tasks, and build tools that other defenders can reuse. That collective learning is one of the strongest arguments for openness: no single vendor team can anticipate every defensive use case, and a community can often find both strengths and flaws faster than a closed team working alone.

For attackers, the same properties are attractive for opposite reasons. An attacker can run the model privately without vendor monitoring, can experiment with prompts and fine-tuning to bypass safeguards, can generate exploit ideas at scale, and can automate parts of reconnaissance and vulnerability analysis that previously required more time and expertise. Mistral observation of potential uplift for real attacks suggests this is not a hypothetical concern. It is a live consideration that should shape how organisations deploy defensive tools and how quickly they patch: if attackers can move faster, defenders must also move faster, and patch timelines become even more important.

The net effect is not a simple win for one side. Open models tend to raise the capability floor for both sides, while the advantage goes to whichever side integrates the capability into disciplined workflows first. A defender who merely downloads a model but does not change triage, testing, and patching processes may gain little. A defender who uses the model to prioritise real flaws, automate reproduction, verify patches, and close the loop with monitoring will gain more. Similarly, an attacker who uses the model casually may gain little, while an attacker who integrates it into a systematic workflow may gain more. Process, not just model access, determines the outcome.

Practical Guidance: Use It Lawfully and Safely

The most important practical guidance is simple: only test systems you own or are explicitly authorised to assess. That principle applies whether the tool is an open model, a commercial scanner, or a manual technique. Testing a system without permission can be unlawful, can cause harm, can violate terms of service, and can expose the tester to legal and professional consequences, even if the intent was curiosity or learning. Authorised testing means written permission, a defined scope, agreed rules of engagement, and a clear process for reporting findings responsibly.

For authorised work, treat Large 4 as an assistant to human expertise, not as a replacement for it. Verify every vulnerability it reports by reproducing it in a safe, controlled environment. Test every patch it proposes against the existing test suite and against edge cases it may not have considered. Review its code changes line by line before merging, because a model can introduce subtle flaws even while fixing an obvious one. Keep humans in the loop for decisions about disclosure, patch priority, and deployment, especially for vulnerabilities that affect customers or critical systems.

For organisations considering self-hosting, plan for the full operational cost, not just the GPU figure. That includes securing the deployment, updating the model and serving framework, monitoring use, logging activity for audit, controlling who can access the model, and ensuring that sensitive inputs are handled according to policy. For organisations considering API use, review data-handling terms, retention policies, and whether code or logs sent to the API could expose secrets or regulated information. In both cases, establish a clear policy for what may be sent to the model and what must stay private.

Finally, stay current on guardrail and licence updates. Mistral says it is tightening guardrails, and licence or access terms for hosted services and specialised variants may evolve. A deployment decision made on release-day terms should be revisited if those terms change, and teams should subscribe to official updates from Mistral rather than relying on second-hand summaries.

What to Watch Next

Several questions will shape how Large 4 is judged over time. Independent reproductions of its benchmarks will show whether the vendor-reported figures hold outside Mistral conditions. Real-world reports from defenders will show whether it finds flaws that matter and whether its patches are reliable. Reports from the security community will show whether safeguards hold up against determined bypass attempts. Updates on the specialised cyber variant will show how Mistral balances openness with restriction in practice.

Pricing and access evolution will also matter. If API pricing changes, or if new hosting routes appear, the cost calculation for small teams will shift. If the hardware floor for self-hosting falls through optimisation, more teams will be able to run the model privately. If new fine-tunes or defensive tools emerge from the community, the practical value of the open release will grow beyond the base model itself.

For now, the fair summary is this: Large 4 is a large, multimodal, long-context open-weights model with strong vendor-reported security and coding benchmarks, broad access routes, a commercially permissive licence with a hosted-service condition, and a safety story that includes both high refusal rates and an honest acknowledgement of uplift risk. That combination makes it important, but it does not make it simple. Readers should explore it with curiosity, verify its claims in their own authorised environments, and keep human judgement at the centre of security work.

Frequently Asked Questions

When was Mistral Large 4 released, and where can it be found?

Answer: The open weights were released on October 29, 2026, on Hugging Face, after a preview on October 6. It is also available via the Mistral API and Mistral Studio, OpenRouter, Microsoft Foundry, and Nvidia NIM, and for self-hosting through vLLM and SGLang.

What does the licence allow, and what needs a separate licence?

Answer: Large 4 uses a modified MIT-style licence under which commercial use is allowed. Hosted-model-service providers need a separate commercial licence, so anyone planning to offer the model itself as a hosted service should check that condition and obtain the separate licence if it applies.

How strong are the reported benchmarks, and should they be taken at face value?

Answer: Reported benchmarks include 51% on the Artificial Analysis Cyber Index, 79% on CyberGym-E2E, 82% on a vulnerability reproduce-and-patch test, 93% on Cybench, 19.7% on FrontierCode 2.0, 41% on Terminal-Bench 4.0, and 48% on the Coding Agent Index. All are vendor-reported or partner-reported and caveated as such in this article, so they should be treated as claims to verify through independent testing, not as independent proof.

How does Large 4 compare with Google Gemini 4 Carbon on access and price?

Answer: Large 4 is open weights with broad access and reported API pricing of approximately $0.70 input and $2.10 output per million tokens, per one report. Gemini 4 Carbon is described as released on October 28 with restricted Fairwind access and reported pricing of $2 input and $10 output per million tokens. The difference is therefore one of open versus restricted access as well as cost, not only capability.

Can anyone use Large 4 to test any system for vulnerabilities?

Answer: No. Only test systems you own or are explicitly authorised to assess, with written permission, a defined scope, and responsible disclosure. Unauthorised testing can be unlawful and harmful, even if the tool used is openly available, and human review remains essential for verifying findings and patches.