Mistral Large 4: Evaluate the API, Then Plan Hosting
MODELS & COSTS
Mistral Large 4: Evaluate the API, Then Plan Hosting
The October preview gives developers an API to test while the weight release remains a separate milestone. Mistral's launch discount can reduce the cost of that trial. A self-hosting budget still needs the actual files, their format and the released license.
In this article
Mistral launched the public preview on October 6, 2026. The API is available now, while the weight release is planned for later this month. My view: the launch offer makes a small, measurable API evaluation worthwhile; a local deployment plan needs the actual files and license first. This is source analysis and original arithmetic, checked October 9. I have not run an API evaluation.
The October 6 preview
The official model card describes a multimodal mixture-of-experts model with 1.05 trillion total parameters and 52 billion active parameters. It accepts text and images and produces text. Function calling and structured outputs are listed, making it relevant to document analysis and tools that need machine-readable answers. The direct API model ID is mistral-large-4; OpenRouter uses mistralai/mistral-large-4-0.
The release is labeled Public Preview. I would treat that status as a reason to test the integration on a bounded workload before making it responsible for an entire workflow. A successful answer in a playground is useful evidence, but it leaves parsing, tool behavior and recovery from failed requests to check.
The launch article reports these coding evaluations. They are vendor-reported results, with benchmark versions retained. I did not reproduce them.
| Evaluation | Reported Large 4 result |
|---|---|
| DeepSWE v1.1 | 61.7% |
| SWE-Atlas-QnA | 59.4% |
| Terminal-Bench 4.0 | 28.3% |
Independent evaluator Artificial Analysis lists an Intelligence Index v4.3.2 score of 38. That is a composite index score, not a 38% task-success rate. Nor can it be averaged with the percentages above: the evaluations ask different questions. For an application, I would keep a separate score for the actual job, such as fields extracted correctly or code changes passing the project’s checks.
The discount on a fixed workload
The official changelog describes a 50% launch discount for two weeks. The model card’s sale rates agree with OpenRouter’s standard Mistral endpoint. Here are US dollars per million tokens. The listed standard row comes from the card’s crossed-out original rates; it is a planning reference, not a guarantee of future pricing.
| Rate / route | Input | Output | Cached input |
|---|---|---|---|
| Launch · direct / standard Mistral | $0.68 | $2.09 | $0.07 |
| Listed standard · model card | $1.36 | $4.18 | $0.14 |
Launch · OpenRouter mistral/eu | $0.748 | $2.299 | $0.077 |
Suppose a workload uses 100 million input tokens and 20 million billed output tokens. With no cached input, the launch-rate calculation is $68 + $41.80 = $109.80. At the listed standard rates, the same counts cost $219.60. That is a useful budget comparison because both sides use the same token counts.
If 90% of those input tokens were billed as cache reads, the sale-rate input cost would be $6.80 for uncached tokens plus $6.30 for cached tokens. Adding the same $41.80 of output gives $54.90. This illustrates the arithmetic of the cache price; it does not establish that a particular integration will achieve a 90% hit rate.
That distinction matters here: the endpoint metadata marks implicit caching as unsupported. A cache-read price is insufficient evidence that repeating a prompt will automatically use it. I would check the route’s caching instructions and actual usage records before including cache savings in a production budget. The no-cache total is the cleaner starting estimate.
The output budget also deserves attention. In the no-cache sale example, output accounts for $41.80 of the total. A longer answer, additional billed reasoning or a retry changes that number. I would record billed output alongside whether the result passed validation, then calculate the cost of accepted results. A discount helps most when the workflow also keeps failed attempts under control.
Routes to the million-token window
The model card says 1M context, and the OpenRouter summary uses the same headline. Looking at the provider endpoint metadata gives a more useful answer: mistral and mistral/zdr list 1,048,576 tokens, while mistral/eu lists 524,288. Each lists a maximum completion of 262,144 tokens.
The European route’s current input, output and cache-read rates are also 10% higher than the standard Mistral route’s. Region selection therefore changes both the limit and the price in this snapshot. I would choose the route needed for the application first, then budget using that route’s numbers.
A context window has to accommodate the conversation as it grows. System instructions, document text, tool results and the response all need room. I would inspect the selected route’s metadata, reserve output space and test representative long requests. The Mistral model API reference exposes a max_context_length field; the particular endpoint and model response matter more than a generic example in the documentation.
For a document task, I would also test whether the model finds evidence buried deep in the input, cites the right passage and handles missing information. Accepting a long request and answering it accurately are separate observations. A larger window is valuable when it preserves the evidence the task needs.
The missing pieces for local hosting
As of October 9, the official Hugging Face page is an upcoming release, with October 31 shown as its current ETA. There is no released checkpoint to deploy from that page yet. The planned date can move, and the final license and file formats still need checking when the artifacts arrive.
The parameter count also changes the meaning of “local.” Activating a subset of experts reduces work per token, but a deployment still needs access to the full set of weights. The 52-billion active count is not a reliable basis for estimating the complete model’s storage.
The arithmetic is total parameters × bits per parameter ÷ eight. At four bits, 1.05 trillion parameters alone correspond to 525 GB. Quantization metadata, runtime buffers, the KV cache and distribution overhead add to the serving plan. Capacity spread across machines also needs a workable way to move data and execute the model.
I covered the same active-versus-total distinction in my Reflection Beam storage analysis. For Large 4, I would wait for published checkpoints and a working serving recipe before pricing a cluster. Buying hardware on the assumption that “52B active” means the whole model occupies roughly that much space would skip the expensive part of the calculation.
Large 4 is worth a focused API trial during the launch offer if the task has a clear acceptance test. I would start with one document workflow or a small set of coding tasks, using the intended region and response format. The useful record is a combination of accepted results, billed tokens, latency and retries. That gives the discount a practical meaning.
Budget an ongoing workload at the listed standard rates. The two-week offer can reduce the cost of an experiment, but it will not cover the life of a deployed service. For local hosting, wait for the checkpoint, license and a working serving recipe before deciding which hardware to buy.
Comments
Post a Comment