A model announcement can look like a product release even when most developers cannot use the model yet. That distinction matters this week: Mistral says Mistral Large 4 weights are now available, while Google's October 28 Gemini 4 Carbon announcement describes a restricted initial rollout to selected cyber defenders and trusted partners. One option can be downloaded and deployed under its license; the other is not yet generally available to developers.
So which one should a team evaluate? The answer is not “whichever benchmark is higher.” As of October 29, 2026, this is primarily a comparison of access paths and rollout plans, not a fair, hands-on contest between two generally available models.
This public-source breakdown separates announced capability from current availability and offers a practical checklist for deciding whether either release is actionable for your team. No hands-on comparison is claimed.
The short answer
- Need a model you can try now? Mistral says Large 4 is available through its public preview API on Mistral Studio. Confirm the current terms, limits, and pricing for your account before planning production use.
- Need Gemini 4 Carbon now? Google's announcement says access starts with a subset of cyber defenders, then expands to trusted partners through its Fairwind program. Developer, business, and consumer access is a later step, not the launch-day offer.
- Need downloadable weights today? Mistral says the weights are available through Hugging Face and names vLLM and SGLang as deployment options. Read the model card and license before committing to self-hosting.
- Need a model choice for production? Wait until both options are actually accessible to your team, then run the same evaluation against your workload.
That is less exciting than declaring a winner. It is also more useful to an engineering team planning a real integration.
What each company has actually announced
Mistral's October 6 post introduced Large 4 as a public preview and said the preview API was available on Mistral Studio. Mistral described it as a one-trillion-parameter natively multimodal model, with 52 billion active parameters, and promised weights by the end of October. Its newer release post says the weights are available, alongside an updated model, improved reasoning efficiency, three reasoning modes, and additional evaluations. Mistral's model documentation classifies Large 4 as open-weight. Check the actual model card and license terms for your use case rather than treating “open-weight” as a complete licensing summary.
Google DeepMind's October 28 announcement calls Gemini 4 Carbon its strongest model for cybersecurity and long-horizon capabilities. Google cites its own and external benchmark results, including 59 on the Artificial Analysis Intelligence Index v5.0, 88.2% on SEC-bench Pro, 54.8% on ExploitGym, and 71.0% on CWE-bench. These are company-reported results; they should be interpreted with each benchmark's task definition and scoring methodology, not as a universal ranking of coding ability.
The access language is the key difference. Google says it is beginning with a subset of cyber defenders and will gradually add trusted partners through Fairwind. It says access for developers, businesses, and consumers through product surfaces will come later, after feedback and guardrail iteration. Carbon's announcement gives an introductory launch price of $2 per million input tokens and $10 per million output tokens, with cached input tokens at a 95% discount. That announced price does not mean every developer can call the model today. Mistral's current model documentation lists API rates of $1.36 per million input tokens, $0.14 per million cached input tokens, and $4.18 per million output tokens. These API rates are not directly equivalent to the cost of self-hosting the weights.
The comparison is therefore not “open versus closed” in the abstract. Mistral says its weights are now published, but deployment still depends on the model card, license, hardware, and serving stack. Google describes Carbon as a restricted rollout, with broader developer access later. Confirm the live terms and availability before making a production plan.
Availability is part of the product
Teams often compare models as if every named release were an API endpoint waiting to be called. In practice, access can decide a project before quality does.
A restricted preview may require an application, an invitation, or a particular use case. A public API may still have preview terms, quotas, changing model behavior, or no production service commitment. Downloadable weights can give deployment flexibility, but only after the artifacts, license, serving requirements, and support path are clear.
Treat these as separate questions:
- Can our team access it now? Check the account and product surface, not just the announcement headline.
- Can we use it for our intended workload? Preview participation may be limited to certain organizations or use cases.
- Can we rely on it in production? Verify terms, quotas, availability commitments, data handling, and support.
- Can we deploy it where policy requires? For a hosted model, inspect provider controls. For weights, inspect license and infrastructure needs.
- Can we measure it fairly? Compare outputs only after both models are accessible under conditions your team can document.
Availability is not an administrative footnote. It determines whether a result can be reproduced, whether a prototype can move to production, and how much work the team must do to get there.
A decision matrix for this week
Mistral Large 4 public preview API
- The stated advantage is that interested developers can try the preview through Mistral Studio.
- The announcement describes a large multimodal model aimed at coding, agentic workflows, and other complex tasks.
- Mistral says the weights are now downloadable; inspect the model card, license, and hardware requirements before designing a self-hosting plan.
- Because it is a preview, confirm the service conditions that matter to your workload instead of assuming the endpoint is production-ready.
Gemini 4 Carbon restricted rollout
- The stated advantage is a model Google positions for cybersecurity and long-horizon work, with published benchmark claims worth investigating.
- Initial availability is deliberately restricted to selected cyber defenders and trusted partners.
- General developer, business, and consumer access is not available at announcement time; Google says it intends to expand access later.
- The announced token price is an introductory future launch price, not evidence of current API access.
Neither as a production decision yet
- If your team cannot access a model, there is no honest way to compare its behavior in your environment.
- If the other is only a preview, a positive test may still not establish production readiness.
- Use the gap to prepare a benchmark set, evaluation criteria, and access questions. That work remains useful after the rollout changes.
Build the evaluation before access arrives
A useful model evaluation does not need thousands of prompts. It needs representative tasks, a clear scoring rule, and a record of what was actually tested.
1. Select 10 to 20 realistic cases. Include normal tasks and edge cases. For security work, use authorized, non-production test material. For coding, choose issues with tests or other observable acceptance criteria.
2. Define success before seeing outputs. Specify what must be correct, what errors are unacceptable, and when a human reviewer must intervene. Do not use “sounds convincing” as the score.
3. Keep a reproducible test record. Store the prompt, model identifier, date, settings, tools enabled, raw output, and scoring result. Record access mode and any preview restrictions too.
4. Measure the whole workflow. Capture latency, retries, usage cost where available, reviewer time, and repair effort. A model that produces a strong first answer but needs repeated correction may be less useful than the headline score suggests.
5. Separate quality from availability. Mark a model “not tested” when you lack access. Do not fill the gap with a vendor benchmark, a social post, or another team's anecdote. Keep vendor-published results in a separate column.
A compact scorecard:
- Access route and eligibility: ___
- Task success rate: ___ / ___
- Critical errors: ___
- Median and worst-case latency: ___
- Cost or infrastructure estimate: ___
- Human review and repair time: ___
- Preview, license, or governance blockers: ___
- Reproduction details saved: yes / no
This avoids the benchmark trap. A vendor's result can tell you what to investigate; it cannot tell you how a model handles your team's repository, policies, or failure cases.
What to verify before acting on the headlines
For Mistral Large 4: Verify the official weights, model card, license, included artifacts, and whether your serving stack can support the architecture and required throughput. The one-trillion total parameter figure and 52-billion active parameter figure describe different aspects of a mixture-of-experts model; neither alone provides a hardware bill. Benchmark your intended inference setup.
For Gemini 4 Carbon: Check whether your organization is eligible for the current rollout, what product or API surface is included, and whether the announced price and terms apply to your use. Google says broader developer and business access will come later, but that is not a date commitment in the announcement.
For both: Record the model version and date. Preview models can change. Re-run critical tests when a model is updated, and do not silently treat an early preview result as a stable production guarantee.
So, which one should you choose?
For an engineer who wants to explore immediately, Mistral Large 4 has the clearer public entry point in its announcement: a preview API on Mistral Studio. That is a statement about access, not proof that it is the better model or the better production service.
For teams working on cybersecurity, Gemini 4 Carbon's stated focus and published evaluations may make it worth tracking or applying to the restricted rollout. But unless the team is included, it cannot yet be evaluated directly. Google's scores should remain vendor-reported evidence until you can inspect the methodology and test the model yourself.
For self-hosting, Mistral's newly published weights make evaluation possible, but the right action is still to verify the files, license, and resource requirements. Do not promise an on-prem deployment before testing the target serving stack.
The practical decision today is therefore: prepare to evaluate Mistral if you have preview access; monitor or apply for Carbon if your use case fits its rollout; make no production winner claim until you can test both.
Bottom line
Mistral Large 4 and Gemini 4 Carbon are interesting for different reasons, but on October 29, 2026, access is the first comparison to make. Mistral says its preview API and weights are available. Google announced a phased, restricted Carbon rollout, with wider access later.
Keep three labels separate in your notes: announced, accessible to us, and validated on our workload. They are not interchangeable. A careful team can prepare its evaluation now, verify the real access state when it matters, and avoid turning a launch post into a production decision.
Save this checklist: verify access, verify terms, preserve model/version details, use representative tasks, measure repair and review time, and separate vendor benchmarks from your results.
Have you ever planned around a model announcement and then discovered access was still restricted? What did your team do while waiting?
Subscribe for more evidence-led comparisons and build guides on developer tools, AI systems, and practical engineering decisions.
Top comments (0)