Mistral Large 4 is available as a public API preview, but its downloadable weights are still to come. Mistral announced the model on 6 October 2026 and says it plans to release the weights by the end of the month. That distinction matters for anyone considering a private deployment: today’s hosted preview lets you evaluate the model; it does not yet let you run it on your own infrastructure. Mistral’s launch announcement sets out that timetable.
The immediate decision for software teams is whether to begin a controlled API evaluation now or wait for the self-hosting release. This report explains the current access, the pricing discrepancy between official pages, and the evidence a team should collect before moving an existing workflow.
News reporting cutoff: 7 October 2026, 18:02 Asia/Karachi (13:02 UTC). Documentation and prices checked on 7 October. This is source-led analysis, not an AIX Radar hands-on benchmark.
What is available now, and what remains planned?
The preview is accessible through Mistral Studio. Mistral describes a multimodal model intended for coding, agent workflows and document-heavy work. Its performance comparisons are company claims; this article does not independently establish that Large 4 beats competing models. The announcement also describes red-teaming before the weight release. Independent reporting from Le Monde corroborates the preview launch.
For now, evaluate the service you can access. Do not assume that hosted-preview latency, moderation, hardware requirements or costs will transfer unchanged to a future private deployment. A downloadable model also needs serving infrastructure, operational support and a confirmed license; an API trial cannot answer all of those questions.
The official pricing page shows a sale, not just list prices
The launch article’s model card shows list prices. Mistral’s API pricing table instead shows the following sale rates alongside crossed-out list rates. All figures below are US dollars per million tokens for the listed Standard offering, checked on 7 October 2026.
| Token type | List rate | Displayed sale rate |
|---|---|---|
| Input | $1.36 | $0.68 |
| Cached input | $0.14 | $0.07 |
| Output | $4.18 | $2.09 |
A hypothetical request using 100,000 uncached input tokens and 10,000 output tokens would cost $0.0889 at those sale rates: $0.068 for input plus $0.0209 for output. At the displayed list rates, the same token counts would cost $0.1778. These are calculations, not measured invoices. They exclude any separate service charges, taxes, retries and your application infrastructure.
Budgeting only against the discounted rate would hide the impact of the offer ending. Keep both rates in your forecast, record the rate actually billed, and set an evaluation spending limit. If your workflow repeatedly sends the same large context, verify cache eligibility and observed cache usage before assuming the cheaper cached rate applies.
Context and architecture: one official discrepancy needs caution
The official model documentation lists a one-million-token context window, structured outputs, function calling and document question answering. Its description gives 1.05 trillion total parameters and 52 billion active parameters. The launch announcement instead uses rounded one-trillion wording and states 49 billion active parameters. Those active counts disagree; this report leaves the difference unresolved rather than choosing the larger number as proof of capability.
The useful question is how much relevant evidence the model can process reliably for your task. A large context limit does not show that a model retrieves every important detail from a long document. Test questions whose answers sit near the beginning, middle and end of a representative file, and separately assess whether the answer cites the right passage. A confident answer with an incorrect citation should count as a failure.
Who has a practical reason to evaluate the preview?
A document-processing team could assess whether Large 4 handles its actual combination of scans, diagrams and text. A coding team could examine repository questions and contained fixes. An organization planning a future private deployment could use the API preview to shortlist workloads, while keeping the deployment decision open until the weights, license and hardware guidance are available.
A small website owner with a working writing workflow has a different decision. Changing models creates migration work even when the token rate looks attractive. The useful comparison is the cost of an acceptable completed task, including manual corrections and retries. Lower token costs do not help if a document requires more review or a formatting error breaks the next step.
For a first evaluation, choose one narrow workflow with a clear acceptance rule. For example, extract an invoice’s line items into a fixed format and compare every field against a verified reference. Keep sensitive documents out of an exploratory account until your organization has reviewed the provider’s applicable data terms.
A controlled evaluation before any migration
- Freeze a representative sample. Include routine inputs, difficult layouts and cases the current system fails. Keep a separate held-out set so prompt tuning does not become the entire evaluation.
- Keep conditions comparable. Record model identifiers, prompts, tool permissions and output limits. Give each model the same evidence unless a difference is deliberately part of the test.
- Measure the whole task. Track accepted outputs, factual and formatting errors, input/output token use, retries, latency and human correction time. Report the sample size alongside any percentage.
- Contain tool actions. Start in a sandbox with explicit permissions. A tool-call response should not receive permission to change files, spend money or contact customers merely because the model requested it.
- Keep a recovery route. Preserve the current workflow and switch only a limited workload after review. Record how to return to it if preview behavior changes.
This sequence is a proposed evaluation method. AIX Radar has not run these tasks on Large 4, so it is not evidence of its speed, accuracy or reliability.
What to watch before the weight release
The next useful checks are whether the promised weights arrive, which license governs them, what deployment guidance accompanies them, and whether the preview’s pricing or behavior changes. Teams considering self-hosting should estimate hardware, serving capacity, monitoring and support costs separately from the hosted token calculation.
Large 4’s preview is a concrete new option to evaluate. It is not yet a completed private-deployment route, and vendor benchmark comparisons should not replace a test of the workload your users actually need.
