Release coverage often collapses “available” into a single day. For Mistral Large 4, the day you can call the API and the day you can download weights are different. This article pins the public timeline, summarizes what changed in the model line, and translates the schedule into concrete engineering actions.
The Timeline You Should Record
Public preview date
On October 6, 2026, Mistral opened a public preview of Mistral Large 4 on its hosted API, including access through Mistral Studio. That is the date most developers can treat as “callable with an account and a key.”
Open weights date
Mistral stated that weights would follow by the end of October 2026. Secondary reporting has mentioned dates around October 27, and placeholder listings have shown end-of-month expectations. Until Mistral publishes the files and a license, treat the weights date as planned, not completed. Verify before publication against Mistral’s official channels on the day you freeze a self-host decision.
Why two dates exist
Shipping a hosted preview first lets Mistral gather usage signal and continue safety work while the checkpoint is still moving. Publishing weights later is a separate operational and legal event: packaging, license text, and a fixed artifact hash. Conflating the two leads teams to promise on-prem dates they cannot keep.
What “preview” means for change control
During preview, behavior can shift as training and moderation work continue. Pin the model identifier you tested, keep a dated evaluation pack, and require a re-run after any announced default change or weights release. Do not assume last week’s completion quality equals next week’s without evidence.
What Changed in the Model Line
Scale and architecture
Large 4 is a step up from Mistral Large 3 in total size and active capacity. Public figures place Large 3 around 675 billion total parameters with on the order of 41 billion active, versus Large 4 near 1.05 trillion total with roughly 49–52 billion active. Both are mixture-of-experts designs. The upgrade is capacity and training scale, not a switch to a dense monolith.
Context length
Large 3 is associated with a 256K-class context window in public comparisons; Large 4 is documented toward a 1M-token window. Longer context changes how you batch documents and how carefully you must manage cost. It does not remove the need for retrieval discipline.
Multimodal limits
Reporting around the launch notes a higher image-per-request ceiling than earlier Mistral Large generations, with a vision encoder on the order of 1.6 billion parameters. If your pipeline attaches many page images, confirm the live per-request limit in docs and enforce a lower application cap for cost and abuse control.
Training and residency narrative
Mistral emphasizes training from scratch on thousands of Grace Blackwell GPUs in its own European datacenters and serving the preview on that footprint. For buyers under EU data-path constraints, that is a material change in the pitch relative to depending solely on non-European hosts. It still does not replace your contractual and technical controls.
Preview Access Versus Weights Access
What you can do on October 6 onward
You can integrate the hosted API, measure latency and token use on your prompts, and trial structured outputs and tool calls. You can also compare behavior against whatever baseline model you already run, under a fixed evaluation harness.
What you cannot do until weights ship
You cannot complete a full on-prem security review of the final checkpoint, pin an immutable local artifact, or finalize license compliance for self-hosting. Any architecture diagram that shows “weights in our VPC” remains aspirational until the files and license exist.
License uncertainty
At preview launch, the weights license was not published. Prior Mistral models have used licenses such as Apache 2.0 for some releases; Large 4’s terms must be read when they appear. Do not assume Apache 2.0 by continuity.
Side-by-side release states
State | Hosted API | Downloadable weights | Typical team action |
|---|---|---|---|
Before Oct 6, 2026 | No Large 4 | No | Track announcement only |
Preview window | Yes | No | Evaluate, do not freeze on-prem |
Weights published | Yes | Yes, if license allows | Re-run evals; decide self-host |
Production freeze | Pinned id or hash | Optional pinned hash | Change control required |
Why the Schedule Matters Operationally
Evaluation windows
Use the preview to build fixtures, not to declare production victory. A two-week preview evaluation should produce a scorecard: schema pass rate, tool-call validity, latency percentiles, and cost per successful task on your data.
Procurement and legal
Security questionnaires will ask whether the model is open-weight and under which license. Honest answers during preview are “API available; weights and license pending.” Overstating openness creates compliance debt.
Cost forecasting
Preview pricing may include temporary discounts relative to list rates. Budget with list economics unless finance accepts promo risk. Track input, output, and cache tokens separately so a discount ending does not surprise you.
Dependency risk
If your roadmap assumes weights on a specific calendar day, put a fallback model and a slip plan in writing. Open-weight slips are common enough that a single-date dependency is a project risk, not a detail.
What Teams Should Do During Preview
Build a frozen test pack
Select a few dozen prompts that represent real traffic: messy JSON cases, long documents, tool-call attempts, and multilingual samples if you need them. Store expected schemas and acceptance checks in version control.
Instrument the client
Log model id, latency, token counts, and validation outcomes. Without those fields, you cannot tell whether a regression came from your code or from a preview checkpoint change.
Separate product claims from system claims
Marketing copy will stress frontier open-weight performance and vertical strength. Your design doc should stress timeouts, retries, validation, and auth. The model proposes; the application decides.
Decision checkpoints
Checkpoint | Pass criteria | If fail |
|---|---|---|
API smoke test | Auth works; simple completion returns | Fix keys, region, model id |
Schema pilot | Structured outputs pass app validators at acceptable rate | Tighten schema; add retries only for transport errors |
Cost pilot | Cost per successful task within budget at list prices | Reduce context; shrink outputs; reconsider model tier |
Weights review | License and hash meet policy | Stay on API or choose another stack |
Takeaway: Two Dates, One Discipline
Remember the split
October 6, 2026 is the API preview. End of October 2026 is the promised weights window. Only the second unlocks self-host binaries, and only a published license unlocks compliance sign-off.
What actually changed for builders
Larger MoE capacity, longer context, stronger multimodal packaging, and a European training-and-serving story. Those are reasons to test. They are not reasons to skip validation or to treat preview behavior as permanent.
Recommended stance
Evaluate now on the API with pinned settings and recorded metrics. Schedule a second evaluation when weights and license land. Keep production writes behind application checks regardless of release excitement.
Boundary
A release date answers when you can call or download a model. It does not answer whether a given completion is safe to execute. That answer remains in your schemas, tests, and authorization layer.
