Mistral Large 4 Preview: Use the API or Wait for Weights

Mistral opened a public preview of Large 4 on October 6, 2026. It is a very large mixture-of-experts model, reported at about 1.05 trillion total parameters with roughly 52 billion active on any given request, a vision encoder bolted on, and a one million token context window listed in Mistral's model documentation. The company has said open weights will follow by the end of October. One outlet puts the date at October 27, but Mistral's own post only says "by the end of the month."

A word on sources before the numbers. I am working from launch coverage, aggregator pages and Mistral's model documentation, and the reports disagree with each other on small things. Early coverage said 49 billion active parameters, later pages say 52 billion. The launch discount is described as a two-week sale in one place and open-ended in another. Treat every figure here as a planning number and confirm it on Mistral's pricing page before you commit a budget.

Two things are missing as of today. There is no published license, and there are no independent benchmark results. Mistral's performance claims are its own, and reinforcement learning on the model was reported as still underway during the preview. That matters more than the parameter count. A founder deciding what to build on does not need the biggest number. They need to know what they are allowed to do with the model and whether it is any good on their task.

So the useful question is narrow. You have an AI feature in production or in planning. Does a new, large, partly open model change what you should do this quarter? For most teams the answer is "test it, do not rewire anything." For a few it is a real opening. The rest of this article sorts you into one group or the other.

As reported, Large 4 lists at $1.36 per million input tokens and $4.18 per million output tokens, with cached input at $0.14 per million. Batch requests are reported at half price. During the launch window Mistral shows a 50 percent cut, which brings the rates to $0.68 input and $2.09 output.

Compare that with the model it replaces. Large 3 was priced at $0.50 input and $1.50 output. Large 4 at list price costs about two and a half to nearly three times as much per token. The discount only brings it back to roughly Large 3 territory for input and a bit above it for output. If your cost model quietly assumed the sale price, you will be surprised the month it ends.

Here is the arithmetic on a feature I see often: a support summarizer that reads 3,000 tokens and writes 400. At 100,000 requests a month that is 300 million input tokens and 40 million output tokens.

• At list price: about $408 for input plus $167 for output, so roughly $575 a month.
• At the launch discount: roughly $290 a month.
• On the small tier of a competitor at $0.10 and $0.50: about $50 a month.

Those are estimates from list prices, not quotes, and your real mix of cached and uncached tokens will move them. The point is the ratio. A frontier-class model is worth paying for when the task needs it. A summarizer usually does not. Our guide to model routing and LLM cost optimization goes through how to send only the hard requests to the expensive tier, and it is the first thing I would apply before getting excited about any new large model.

My advice on the discount is simple. Budget at list price. If the sale holds, you bank the difference. If it ends, nothing changes in your plan.

I split founders into three groups when a model like this lands. Find yours.

You call a hosted model API today and it works

Do nothing structural. Add Large 4 to your evaluation set, run your own prompts through it, and look at the results next week. A preview model changes under you. Mistral can adjust weights, rate limits and pricing while the label says preview, and your production feature should not depend on that. Keep the model name configurable in one place so a swap is a one-line change, not a refactor.

You are locked out of hosted APIs by a contract or a regulator

This is the group the weights matter to. Health, legal, finance and government work often cannot send data to a third-party model API at all. For you, a frontier-sized open-weight model is the first plausible way to run something strong inside your own cloud account. But do not plan around it until the license is published. A license that bans commercial use above a revenue threshold, or restricts certain fields, ends the plan on day one.

You are an early-stage team with no AI feature live yet

Pick any good hosted model and ship. Your risk is not choosing the wrong model. Your risk is spending two months on infrastructure for traffic you do not have. A trillion-parameter model needs a rack of accelerators to host, and that is a cost you will not recover at ten thousand requests a day.

If you are not sure which group you are in, our earlier piece on self-hosting open-weight frontier models versus paying the API has the cost breakpoints. The short version is that self-hosting starts to win somewhere in the tens of millions of tokens a day, and only when someone on your team can run GPU infrastructure.

Say the weights drop on schedule and the license is permissive. What do you need to run it?

A model with about a trillion total parameters does not fit on one machine. Even stored at 8-bit precision the weights alone are around a terabyte, which means a multi-node setup or a single node with a lot of high-memory accelerators. Mixture-of-experts helps with compute, since only about 52 billion parameters are active per token, but it does not help with memory. Every expert has to be loaded and reachable, so the bill is set by the memory footprint, not the active count.

In practice, you are looking at one of three paths.

• Rent a managed endpoint. Cloud providers and inference hosts will offer the weights within days of release. You pay per token or per reserved hour, and you keep your data inside a contract you chose. This is the right default for nearly everyone.
• Reserve GPUs yourself. A node of eight top-end accelerators runs well into five figures a month on reserved pricing, and you likely need more than one for a model this size plus redundancy. Plan for an engineer who owns it part time at minimum.
• Run a quantized version. Community quantizations usually appear within a week or two. They fit on less hardware and lose some quality, and how much depends on the task. Measure it on your data, not on a leaderboard.

Then add the parts people forget: a serving stack such as vLLM or SGLang, autoscaling that does not strand a six-figure cluster idle overnight, observability on latency and token throughput, and a plan for patching the stack. I have seen a team save 30 percent on tokens and spend the savings twice over on the person hired to keep the cluster alive.

You do not need a benchmark suite to form an opinion. You need your own prompts and a clear idea of what a good answer looks like.

1. Pull 50 to 100 real inputs from your logs. Strip personal data. Include the ugly ones: long, misspelled, off-topic, adversarial.
2. Write the pass condition for each category before you see any outputs. "Extracts the invoice total correctly" is a pass condition. "Sounds good" is not.
3. Run the same inputs through your current model and Large 4. Keep temperature and system prompt identical. Save both outputs side by side.
4. Score blind. Have someone who did not write the prompts grade the pairs without knowing which model produced which.
5. Record cost and latency per request. A model that is 4 percent better and twice as slow is often a loss for a chat feature and a win for an overnight batch job.

If you have never set up this kind of check, how to evaluate LLM quality walks through the scoring setup in more detail. The thing to watch for with a preview model is variance. Run the same prompt several times. If the answers swing widely from run to run, that is a signal the model is still being tuned, and a reason to wait.

Also test the one-million-token context claim on your own documents, not on a needle-in-a-haystack demo. Long context that retrieves a single planted fact can still lose track of three clauses that interact. If your product depends on long documents, build a test where the answer needs two facts from opposite ends of the input.

Open weights is a loose phrase. It can mean a permissive license like Apache 2.0, a custom license with revenue caps, or a research-only release. Mistral has used different terms across different models, so history does not tell you what this one will say. When the license lands, read it for these items before anyone writes code.

• Commercial use. Allowed outright, allowed under a revenue or user threshold, or banned?
• Hosting for others. If you sell a product that runs the model, does that count as redistribution?
• Fine-tuning and derivatives. Can you keep your tuned weights private? Do you have to publish them or carry the same license?
• Use restrictions. Some licenses bar particular industries or require attribution in product UI.
• Change terms. Can the vendor update the license for versions you already deployed?

Have a lawyer read it if the model sits inside a product you sell. This is the cheapest hour you will spend this quarter. And keep a note of the license version and date next to the model version in your repository, so that two years from now you can show what you agreed to.

The same discipline applies to data. Mistral is a French company, and a European host or a European region of a cloud may matter for your customers' contracts. Hosted preview traffic goes to Mistral's API, so check the data processing terms and the retention policy before you send anything sensitive, even test data that looks harmless.

The mistake I see most is treating model choice as one decision. It is several. A real product has a cheap tier for classification and extraction, a mid tier for drafting and chat, and a top tier for hard reasoning and agent planning. A model like Large 4 competes for the top tier and maybe part of the middle.

Consider a document workflow for an insurance startup. Intake classification goes to a small model at a fraction of a cent per thousand requests. Field extraction goes to a mid-priced model with a strict schema. Only the claims that fail validation, perhaps one in twenty, go to the expensive model for a second look. In that design, the question "is Large 4 better than what we use" becomes "is it better on the one in twenty claims that matter, at a price that makes sense for that volume." That is a far easier test to pass, and far easier to run.

It also changes the economics of the discount. If only 5 percent of traffic reaches the top tier, even list price is a rounding error on your monthly bill. The savings and the risks both live in the other 95 percent, where the cheap tier is doing the work. For a view of that tier, our comparison of GPT-6 Luna and Claude Haiku 5.5 is the place to start.

Here is what I would do if I ran the AI work at a seed-stage company today.

This week. Run the afternoon test above against the preview API. Spend a few dollars, not a few hundred. Put the result in a doc with the date, the model name as the API reports it, and the prices you paid. Make sure your code reads the model name from config.

When the weights and license land. Read the license. If it blocks you, close the topic. If it permits you, check whether a managed host offers it at a price below Mistral's own API, because that is the cheapest way to get the benefits of open weights without the operations work.

In 30 days. Rerun the same test. Preview models change, independent benchmarks arrive, and the price may move. Decide then whether any traffic should shift. If your answer is still "no," that is a fine outcome. The goal of this exercise is not to adopt a new model. It is to know, with evidence, that you do not need one.

The cost of being wrong in either direction is real. Adopt too early and you rebuild when the preview changes. Ignore it entirely and you may pay a premium for months on a task a cheaper model now handles. A small, repeatable test is how you avoid both.

If you want a second pair of eyes on your model stack, or you are deciding whether an AI feature belongs in your product at all, we do this work every week. Book a free strategy call and bring your current prompts and your monthly token bill.