Mistral Large 4 is an API preview today; open-weight deployment remains a later gate

The 6 October announcement promises weights by month-end. Teams can prepare an evaluation now without pretending the downloadable model has arrived.

A promised open-weight release is not the same thing as downloadable weights. Mistral introduced Large 4 on 6 October 2026 as a public API preview, with weights planned for the end of the month. That distinction is explicit in the [announcement](https://mistral.ai/news/mistral-large-4/). As of this 14 October review, a team can investigate the preview’s suitability and prepare a local-hosting plan, but it should not claim to have adopted a weight package that the reviewed source says is still forthcoming.

The model is described as a large multimodal mixture of experts. That architecture separates total parameters from the subset active for a token. It does not make hosting requirements equal to the active parameter count. Weights, routing, memory movement and context state still affect deployment. Avoid turning a sparse-model headline into a hardware quotation. Capacity should come from the actual artifact and serving configuration once available.

An original evaluation plan could focus on visual issue triage. Prepare screenshots of a fictional application with source-code excerpts and a written acceptance rule. Ask the preview to identify a UI inconsistency, explain its evidence and propose a small repair. Include a screenshot where the visible symptom is caused by a missing data state, so the model cannot succeed by merely changing CSS until the image resembles an example.

Keep the hosted-preview baseline separate from any later local test. Record the model identifier, date, prompt, input artifacts and permitted tools. When weights arrive, retain the checkpoint version, runtime, quantization and hardware configuration. Compare accepted outcomes rather than expecting identical prose. Differences may come from model revisions or serving details; the evaluation record should make those possibilities visible.

The [model documentation](https://docs.mistral.ai/models/mistral-large-4) provides the specific API route and product state. Check whether a capability is supported by that route, not only mentioned in a release narrative. Preview services can change more quickly than stable products. Production migration should therefore include a documented rollback path and avoid depending on an unconfirmed feature for a critical workflow.

For the visual triage example, reviewers should grade diagnosis, patch scope and actual behavior separately. A correct observation that a button is missing does not prove the proposed implementation respects authorization or keyboard use. Run the patch in an isolated project environment and check desktop and narrow-screen states. Preserve licensed components rather than replacing a working interface with a screenshot background.

Mistral’s announcement includes vendor performance claims. They are useful pointers to evaluations worth reading, but this article does not independently reproduce them. A model that performs strongly on one coding or professional-work benchmark may still fail the team’s permissions, style or evidence requirements. Use a held-out task set and count the cases that stop honestly because information is unavailable.

Licensing remains a concrete future check. Once the weights are published, inspect the license attached to that exact release and preserve it with the artifact. Do not infer Apache 2.0 merely because another Mistral model uses it. Open weights describe access to the checkpoint; open-source claims require a broader assessment of what is supplied and the rights granted. A hosted SDK’s license is also separate from the model’s rights.

Budget the preview and prospective local route independently. Hosted inference can be convenient for a small pilot, while local hosting can provide operational control at the cost of hardware and maintenance. A model with substantial storage requirements may be impractical for a lightly used service even if only part of it activates per token. Include idle capacity, updates, monitoring and reviewer time in the estimate.

The useful near-term work is a reusable test corpus, documented acceptance criteria and a source-backed availability record. The deployment decision can follow when the actual release, rights and serving requirements are known. Large 4 creates a current opportunity to evaluate a European frontier option. Its promise of openness should remain a dated promise until the downloadable artifact is available and inspected.

Keep an availability checklist with separate boxes for API preview, published weights, inspected license and accepted local serving. A dated announcement can satisfy only the state it actually establishes; the other boxes need their own evidence.