Mistral Large 4 Gives Buyers a One-Month Exit Clock • The Weighted Average

Buy a reversible pilot, not a permanent dependency

Engineering teams evaluating Mistral Large 4’s October 6 public preview should budget for a reversible pilot: its release stage carries one month’s retirement notice, rather than the six months offered to general-availability models. Combining the Large 4 card’s Public Preview classification with Mistral’s lifecycle policy yields 83.3% less notice after deprecation—a procurement constraint that matters more than another position on a benchmark leaderboard.

That is not a prediction that the model will disappear next month. The notice period begins with deprecation; it does not begin with today’s launch. Nor does it mean the preview will remain unchanged until retirement. The policy permits silent updates during Public Preview and offers no guaranteed progression to General Availability. A team can therefore receive a changing service while preparing for a relatively short eventual migration window. The sensible purchase is an experiment whose results and replacement path remain usable when the service changes.

The offer is nevertheless worth testing. Mistral’s announcement says the preview API is available now and the weights are due by the end of the month. Those are different delivery milestones. An API evaluation can establish whether the model helps with a particular workflow today; it cannot establish the cost or operational readiness of a private deployment whose release artifacts have not arrived. A prospective self-hosting buyer should keep those two decisions on separate schedules.

This distinction extends the archive’s analysis of Mistral’s sovereign deployment obligations. Financing and control ambitions made the supplier worth considering. The new model adds a candidate to evaluate, but its preview status introduces an immediate engineering obligation: preserve the ability to rerun the evaluation and withdraw the candidate. Supplier independence is useful only if the customer’s own system does not become dependent on an unrepeatable test.

Today’s Reflection Beam brief examines another preview API’s migration contract, while the North 2 analysis asks whether documented cost controls enforce the intended budget. The common buying question is what the actual service promises. A model’s name, a platform launch, and an attractive price each help form a shortlist. None establishes that the selected configuration meets a production obligation.

The discount and the exit clock run separately

The notice comparison is deliberately narrow. Mistral Large 3 is labeled GA, while Large 4 is labeled Public Preview. The lifecycle table assigns six months and one month respectively. Subtracting leaves five fewer months; dividing that difference by six gives (6 − 1) ÷ 6 × 100 = 83.3%, rounded. This joins the model-specific classifications to the platform policy, rather than assuming the newer model inherits its predecessor’s support terms.

Mistral previews offer five fewer months to migrate

Retirement notice after deprecation, months · October 6, 2026

Mistral model lifecycle policy · October 6, 2026

The practical consequence is a tighter migration rehearsal. Keep the incumbent route callable, maintain the input and acceptance criteria used for the pilot, and test the fallback before expanding traffic. A replacement that returns valid text but fails the business task is not an exit path. Teams with long customer approval cycles should establish whether their own revalidation process fits inside the published notice period before making the preview a required dependency.

Price has a separate clock. The current pricing table shows Large 4 sale rates of $0.68 per million input tokens and $2.09 per million output tokens, against displayed original rates of $1.36 and $4.18. Each sale rate is 50% lower. That establishes the size of the displayed discount; it does not establish a contractual duration for it. A budget should retain both columns so the pilot cannot pass merely because its test period happened to coincide with a promotion.

Discounts also need a valid deployment path. Mistral’s Batch documentation offers a 50% discount for asynchronous processing. That is a separate service claim, not permission to compound every discount shown elsewhere. Confirm the model, billing terms, and eligible endpoint before counting a combined saving. Work that requires an immediate response should also be evaluated as immediate-response work; a cheaper asynchronous route is valuable only when the application can tolerate it.

Predictable access has another price. The Priority Tier guide specifies a 1.75-times multiplier on standard list pricing, requires account setup, and makes availability model- and capacity-dependent. A procurement spreadsheet can use that rule to frame questions, but it should not label a calculated Large 4 Priority price as an available quote without confirming eligibility. Record the service tier that actually handled the request, especially where the configured route permits fallback to Standard.

The most useful cost comparison is consequently measured at the workflow boundary. Retain input and output usage, the applicable tariff, retries, review effort, and whether the result was accepted. The sale price can reduce one component while a longer answer or more review increases another. A model that completes valuable work at a lower total cost may justify the operational burden of a preview. A low token rate alone cannot do that accounting.

The documentation is still catching up with the model

The launch contains reasons for optimism, but the public descriptions are not fully aligned. Mistral’s announcement describes 1 trillion total and 49 billion active parameters. Its model card lists 1.05 trillion total and 52 billion active parameters, plus a vision encoder. This article does not resolve that discrepancy by choosing the larger or newer-looking number. Teams planning memory, throughput, or serving infrastructure should obtain a release-specific architecture description before treating either summary as a hardware specification.

That is a particularly consequential distinction for mixture-of-experts models. The archive’s Kolibri analysis separates weight size from usable serving capacity. The same diligence applies here: a count in a launch paragraph is not a procurement-ready system configuration. Wait for the actual release artifacts, supported runtime, and measured workload behavior before translating architecture claims into a hardware order. An API pilot can proceed without pretending those questions are already answered.

Evaluation pages introduce another configuration boundary. Vals lists a 512k context window for its Large 4 entry, while Mistral’s model card advertises 1M. Vals also discloses its default provider and generation settings, and cautions that individual benchmarks may differ. These descriptions are evidence about the published product and evaluated configuration; they are not proof that every account, endpoint, or benchmark exercised the same window. Verify the limit that the intended endpoint actually accepts.

Speed deserves equally careful reading. Artificial Analysis reports 116.1 output tokens per second for Large 4 Preview, while defining output speed as the rate after generation begins. That number does not include all of the time a user waits for a finished, accepted result. A workflow evaluation should measure elapsed completion time and any review or retry cycle, rather than apply a streaming rate to the entire business process.

None of these caveats establishes that Large 4 is a poor model. The strongest case for early adoption is a bounded task where it delivers a measurable advantage and the surrounding application can absorb change. A document-analysis team might value the model’s multimodal capabilities enough to run a supervised comparison now. The burden is to demonstrate that advantage on its own material, retain failure examples, and distinguish vendor-reported capability from locally reproduced results.

The thesis would weaken if a customer obtained stable, deployment-specific terms that removed the relevant preview risks. It would also change after a GA transition, a usable weights release, or a successful private deployment with a tested replacement route. Conversely, unexplained output changes, inadequate fallback quality, or a promotion-dependent cost advantage would strengthen the case for delaying broader adoption. The verdict should move with those observations, rather than with the emotional force of an open-model launch.

Make the pilot survive a change of plan

Start with a deployment contract, then choose the test. Regional inference documentation limits regional tools to function calling and excludes stateful Agents, Batch, and Files. It also says model availability varies by region and that control-plane information may be handled elsewhere. A regional endpoint therefore requires its own feature and availability check. Do not approve an architecture that needs a service the selected endpoint explicitly excludes.

Retention is a different question. Mistral’s zero-data-retention guide covers supported stateless calls and excludes stateful products. Regional processing, retention, and permission to use a feature should each be recorded as separate requirements. A successful chat-completion request establishes connectivity. It does not establish that a file-based or stateful workflow inherits the same data-handling terms.

Turn those requirements into an acceptance record the next engineer can use. Record the endpoint, model identifier, observed limits, tariff, relevant account settings, and date of the run. Keep the representative inputs and the rubric for accepting their outputs. When the preview changes, rerun the same work and compare the resulting artifacts. Pinning an identifier is useful for traceability, but it should not be mistaken for a promise of immutable preview behavior when the published lifecycle explicitly permits silent updates.

Set the expansion decision before collecting the attractive examples. Specify which errors would prevent use, who reviews an ambiguous result, and what happens when the preferred model is unavailable. Include rejected and interrupted tasks in the cost record. Otherwise a pilot can appear cheap by counting only the work that finished cleanly while moving the repair bill into somebody else’s queue. The purpose of a controlled trial is to expose that bill while it is still small enough to understand.

Keep self-hosting on a separate approval path. The promised weights release may eventually make a different balance of control and operating cost possible. Until then, require the actual artifact, applicable license, supported serving configuration, and workload evidence before claiming the API experiment proves private deployment readiness. This preserves the value of learning now without spending tomorrow’s infrastructure budget against a delivery promise.

For this quarter, the action list is specific:

Engineering leads: shortlist Large 4 for a bounded, supervised pilot where a replacement route can be exercised. Prove that the fallback completes the same task before increasing dependency on the preview.
Finance and procurement: price the observed usage at both the displayed sale and original rates. Confirm any Priority, regional, or Batch terms for the intended configuration instead of stacking published discounts by assumption.
Platform owners: retain dated evaluation inputs, accepted outputs, failure cases, endpoint settings, and a named migration owner. Check whether internal reapproval can fit the preview’s notice period.
Teams seeking private deployment: wait for the weights and serving evidence before ordering capacity. Revisit the decision when the promised release and deployment terms can be inspected.

Large 4 makes a new evaluation worth running. Its preview status makes the exit rehearsal part of that evaluation. The buyer who can preserve both the learning and the ability to leave has the strongest position when the model, its price, or its release stage changes.