Mistral Large 4 weights are open. The license has a catch.

On October 29, 2026 Mistral put the weights of Large 4 on the table: a 1 trillion parameter mixture of experts model, free to download, free to fine tune. The Hacker News front page had it at 719 points the same day, and most of the thread reads like a victory lap for open models. The victory is real. The word "open" is doing more work than it used to, though, and the gap between what it promises and what it costs is where teams will lose money this quarter.

What Mistral actually released

Start with the facts that are on the page. According to Mistral's announcement, Large 4 is a mixture of experts model with 1 trillion total parameters, released as open weights under what the company names the Mistral Ecosystem Open Weight license. Mistral describes that license as a modified MIT license. The modification that matters is a carve out: operators who offer the model as a service, the Model as a Service or MaaS business, need a separate commercial license from Mistral.

That is a short sentence with a long shadow. MIT is the license people reach for when they want zero friction. It says take it, change it, sell it, keep the copyright notice. A modified MIT license is a different object. Every modification is a place where a lawyer will have a question, and this one has an obvious commercial motive: it keeps the large inference clouds from turning Mistral's own model into their margin without paying for it.

I am describing the license as Mistral describes it. I have not reproduced its text here, and nothing in this post is legal advice. The practical consequence of that gap is simple: read the actual license file in the release before you design anything around it, and have someone who is paid to read licenses read it too. The checklist later in this post tells you which questions to bring.

Open now has a business model

For a few years "open weights" was shorthand for a particular bargain. A lab with something to prove, usually a smaller lab, released a model, collected goodwill and developer mindshare, and made money somewhere else. The weights were a marketing budget with a download link.

Large 4 shows the next version of the bargain. The weights are genuinely usable. You can run them, adapt them, and build on them without asking. The one use that would let someone else capture the revenue that Mistral's API depends on, selling the model as a hosted service, is the one that costs a license fee. It is a sensible line to draw. It is also a reminder that open weights is a spectrum, and that your position on it is set by a clause, not by a press release headline.

For a builder there are two honest readings. The generous one: Mistral found a way to ship a trillion parameter model to everyone while still having a business, and that beats the alternative where the model stays closed. The skeptical one: the freedom is real for the people least likely to compete with Mistral and conditional for the people most likely to. Both readings are true at once. Which one governs your project depends entirely on what your product sells.

The comparison nobody makes: self hosting against the API, not against zero

The most common mistake in open weights economics is comparing the cost of running a model with the cost of nothing. Teams look at an API bill, see a number that feels large, and conclude that free weights must be cheaper. The weights are free. The machines, the engineers, and the pager rotation are not.

The right comparison is against the cheapest credible API for the same model, and here Mistral has already set the bar. Its pricing is $0.70 per million input tokens and $2.10 per million output tokens, with cached input at $0.07. If your prompts share a long prefix, such as a system prompt or a codebase summary, the cached rate makes that part of the input one tenth of the list price. That is a hard number for a self hosted cluster to beat.

Then there is the frontier comparison. Google lists Gemini 4 Carbon at $4 per million input tokens and $20 per million output tokens after its introductory pricing. Divide: Carbon costs about 5.7 times as much on input and about 9.5 times as much on output as Large 4 through Mistral's own API. That ratio is the headline for anyone choosing a model on cost, and it has nothing to do with the weights being open. The open weights are the option you hold in your pocket. The cheap API is the thing you can use today.

Notice what the comparison leaves out: quality. A cheaper model that fails more tasks is not cheaper. That is the argument in the multi model stack and it applies in both directions. Carbon's price tag buys something, and the next section is about measuring what.

What the leaderboards say, and what they leave out

Quality claims around a release day are mostly vendor claims. Here is the vendor's. Mistral reports that Large 4 scores 41% on Terminal-Bench 4.0, and describes it as the best open weight model for coding. I am labelling both as vendor reported, because they are: a number the model's maker published about its own model, on a benchmark and under conditions the maker chose.

That does not make them wrong. It makes them an opening bid. A 41% on a terminal task benchmark tells you the model completes a bit over two in five of those tasks under that harness. It does not tell you how it behaves on your repository, with your tools, under your timeouts. Benchmarks measure a model plus a harness plus a scoring rule, and your workload is a different triple.

For a sense of how contested the top of the board is, look at the independent side. Artificial Analysis reports Kimi K3.1 Pro at 1678 Elo on AA-Briefcase against 1609 for Gemini 4 Carbon, a gap of 69 points. I will not claim to know more about that benchmark than the headline numbers, and I will not claim Large 4 sits anywhere on it, because the source does not say. The useful lesson is the shape: a challenger can outscore a frontier flagship on an independent board, so a single vendor's price and launch story is not the whole picture.

If rankings that fluid decide your architecture, you will rebuild it every month. If your own evals decide it, you can swap models in an afternoon. The second posture is the one in eval driven development: write the tests that define good for your product first, and let every new model, open or closed, sit the same exam. Large 4 is a good reason to run that exam this week. It is not a reason to skip it.

The hardware floor

Now the part that decides who self hosts. The parameter count is public: 1 trillion. A parameter stored at 16 bits takes 2 bytes, so the weights alone are about 2 terabytes. At 8 bits they are about 1 terabyte, and at 4 bits about 500 gigabytes. That is arithmetic on the parameter count, not a figure from Mistral, and it covers the weights only. The serving cache that grows with context length and with the number of concurrent requests sits on top.

A mixture of experts design helps with compute per token, because only a subset of experts fire for each token. It does not help with memory. Every expert has to be resident somewhere fast, or you pay in latency while they load. I am not going to quote an active parameter count, because the sources I am working from state the total and not the split. Check the model card for it, since it drives your throughput planning.

What follows from the memory math is a fork in the road. You can lease or buy a multi GPU system large enough to hold the weights in a compact format, and keep it busy. Or you can use a quantised variant that trades some quality for a smaller footprint, and then you have a second eval to run, because the quantised model is a different model from the one on the benchmark chart. Both paths cost real money before the first user arrives, and both have a minimum size. There is no such thing as a small, cheap, self hosted trillion parameter deployment.

That is why the small model routing playbook matters more than the release headline for most teams. For the bulk of requests in a typical product, a far smaller model clears the bar, and the question of whether to rent a trillion parameters is relevant only to the hard residue that the small model escalates.

A break even outline you can fill in

I do not know your GPU price, your utilisation, or your salary bands, and I am not going to invent them. What I can give you is the structure of the calculation, with the API side filled in from published prices. Plug in your own numbers on the other side.

Step 1: price your current token volume on the API

Take a month of real traffic. Count input tokens, output tokens, and the share of input that repeats a cached prefix. Then apply the published rates: $0.70 per million for fresh input, $0.07 per million for cached input, $2.10 per million for output.

A worked example with made up traffic, clearly hypothetical: 2 billion input tokens and 400 million output tokens a month. With no caching, input costs 2,000 times $0.70, which is $1,400, and output costs 400 times $2.10, which is $840. Total: $2,240 a month. Now suppose 60% of input hits the cache. Fresh input is 800 million tokens, which is $560. Cached input is 1.2 billion tokens at $0.07 per million, which is $84. Output is unchanged at $840. Total: $1,484 a month.

Read that number slowly. A product moving 2.4 billion tokens a month, which feels like a lot, has an API bill of roughly $1,500 to $2,200. That does not pay for a part time infrastructure engineer, let alone a cluster. Your traffic will differ, and I would not be surprised if it is ten or a hundred times larger, but do the multiplication before you take the cluster quote to finance.

Step 2: price the self hosted alternative honestly

Sum four lines, per month. Hardware: the lease or amortised purchase cost of the GPU system that holds the weights with headroom for the serving cache. People: the fraction of engineers who build, monitor, patch and get paged for the serving stack, priced at fully loaded cost. Idle: the hours the system is provisioned but not serving, since you pay for peak, not average. Switching: the engineering time to move off the API and the time to move back if the experiment fails.

Call the total S. Most teams stop at the hardware line, and that is the line most likely to be the smallest of the four once the system is in production.

Step 3: compute the break even and apply a margin

Let A be your monthly API bill at the published Mistral rates. Self hosting wins on cost only when A is meaningfully greater than S. I would not move for less than a factor of two, because S is an estimate and estimates for infrastructure projects skew optimistic. A two times margin is the cushion that absorbs the first incident, the first model update, and the first quarter where traffic dips.

Rearranged, the break even monthly volume is S divided by the blended API price per token. In the example above, with no caching, the blended price is $2,240 over 2.4 billion tokens, about $0.93 per million tokens. Whatever S turns out to be, divide it by that figure and you get the token volume at which the two options tie. Then compare that volume with the volume you actually have, and with the volume you will have in a year if the product works.

The token pricing story is the cautionary tale on the other side of this ledger: when usage grows faster than budgets, the API bill really does become a board level number. If that is where you are, the arithmetic above will tell you quickly, and the answer may well be to self host. But it is a conclusion from a spreadsheet, not from a release announcement. Put quality in that spreadsheet too: the comparison only holds if you divide by solved tasks rather than tokens, as we argue in measuring cost per task instead of price per token. A routed setup like the one in the Copilot Fusion margin fight changes the volume you would send to any one model.

Decision rule: when open weights actually save money

Boil the outline down to a rule you can say in a meeting. Stay on the API when any of these is true: your bill is under twice your fully loaded self hosting cost, your traffic is spiky enough that you would pay for idle capacity most of the day, or you have no one whose job includes keeping an inference cluster alive. The API's price per token already includes somebody else's utilisation, and at $0.70 and $2.10 that is a bargain you should not discount.

Self host when the cost test passes and you can name the reasons beyond cost. Four reasons come up repeatedly in real engagements.

• Data residency or air gapping. If prompts cannot leave your network, the API is not an option at any price, and the weights are the only way to use this class of model. This is the same logic behind the sovereign stack, where the boundary of the deployment is a legal fact rather than a preference.
• Fine tuning on private data. The weights are free to adapt, so you can train on material that you could never send to a vendor. Whether a trillion parameter model is the right base for that, rather than a much smaller one, is an eval question and a budget question.
• Version pinning. An API model can be updated or retired on the vendor's schedule. A set of weights on your disk behaves the same way in March as it did in October. For regulated workflows with validation requirements, that stability is worth a premium.
• Latency control. Running next to your own data and your own network removes a hop and a shared queue. Whether that matters depends on whether your users can feel the difference, which is measurable, and worth measuring first.

Notice that each of these is a reason to hold the weights, not a reason to call them cheap. The teams that do well with open models tend to arrive with one of these four needs and then discover that the economics also work. The teams that arrive with only the economics tend to discover the other lines in the spreadsheet.

A license checklist before you build

Because the commercial question is the one most likely to go wrong later, put it first, in writing, with a name next to each item. These are the questions to take to whoever reads your contracts. I have framed them from Mistral's published description and not from the license text, so confirm each against the file in the release.

• Do we offer access to the model, directly or through an API, to customers who pay us? If yes, assume the MaaS clause is in play and ask Mistral for commercial terms before launch.
• Do we embed the model inside a product where the customer never sees a prompt box? Ask how the license treats that case, in writing, and keep the answer with your vendor files.
• Do we run the model on behalf of a client inside the client's own environment? Find out whether that makes us the operator or the client the operator.
• Which version of the license applies to the weights we downloaded, and where is the copy we archived? Store the exact license text next to the exact weights hash.
• Does our fine tuned derivative inherit the same terms? Assume it does until counsel says otherwise, and check what the license says about distributing the adapted weights.
• Are our customers' contracts compatible with an upstream license that can differ from MIT in the places that matter? Flow down any restriction you cannot meet.
• Who owns the review when Mistral ships the next release under a different license? Put a calendar date on it. License drift between versions is a quiet source of risk.

None of this is hostile to the open model. It is the same diligence you would run on any dependency with commercial terms. The reason to say it out loud is that "open" in a headline reads as permission, and permission is exactly what the first three items on the list test.

Why the hype is both right and misleading

The 719 point thread on Hacker News is a good indicator of attention and a poor indicator of fit. Attention is not nothing. It means thousands of engineers will try the weights this week, find the rough edges, and publish their results. That feedback loop is a real advantage of open releases, and it will tell us more about Large 4's behaviour in a month than the launch page does today.

But a front page score cannot see your workload. It cannot see that your product does ten million small classification calls and two thousand hard reasoning calls. It cannot see that your customers are in a jurisdiction that bans cross border inference, or that the margin on your cheapest plan leaves a fixed few cents of model cost per user. Those facts are yours. They decide whether the right answer is the API, a smaller open model, a routed mix, or a rented cluster.

There is also a wider pattern. Teams that bet their roadmap on one model's launch week tend to bet again the next week. The durable position is to keep the model swappable: a thin interface, an eval suite, and a routing layer that can send each request to the cheapest model that clears the bar. Large 4 makes that position more valuable, since it puts a credible, cheap, and open option into the pool. It does not remove the need to have the pool. The same logic runs through the open source coding agent story: when the tools are open and the models are interchangeable, the advantage moves to whoever has the best measurement.

Three scenarios, three answers

A startup with an AI feature and a small team

Use the API. Mistral's $0.70 and $2.10 per million are low enough that your token bill is probably a rounding error next to payroll, and the engineering time you would spend on a serving stack is time you are not spending on the product. Run Large 4 through your eval suite against whatever you use now. If it clears the bar, the savings arrive by editing a model name and a price constant. If your product is itself an inference API, call Mistral about the commercial license first.

A mid size company with a steady, heavy workload

Run the break even outline with real numbers. If A is more than twice S and the load is steady enough to keep the hardware busy, a pilot is justified, with the API as the fallback. Keep the interface identical so you can flip traffic back in minutes. Measure the quantised variant separately from the full precision one, and do not assume the benchmark chart applies to either until you have tested it on your data.

A regulated enterprise with data that cannot leave

Here the weights are not an optimisation, they are the way in. Cost matters less than control, and the real questions are about people and process: who operates the cluster, who validates each model version, who approves the license terms for internal use. The cost rule still applies as a sanity check on the size of the deployment, but it is not the gate.

What to do this week

Five actions, each small enough to finish before Friday.

• Pull a week of production traffic and count input tokens, output tokens, and the repeated prefix share. You need these three numbers for any cost conversation, and most teams do not have them.
• Price that traffic at $0.70, $0.07 and $2.10 per million. Write the result at the top of a shared note, next to your current provider's bill for the same traffic.
• Run your own eval set against Large 4 through the API. Do not wait for the weights to be in your cluster to learn whether the model is any good for your task. Compare it with your current model and, if you have budget, with Carbon at its listed $4 and $20.
• Read the license file in the release, then send the checklist above to whoever reviews contracts. Ask for a one page answer on the MaaS question as it applies to your product.
• Get a hardware quote for holding a 1 trillion parameter model at the precision you would actually use, and add the people and idle lines before comparing it with step two. If the quote is the first time anyone has asked what the weights cost to hold, that is a result in itself.

By Friday you will know three things: what the API route costs you, whether the model is good enough for your task, and whether the license permits the shape of your business. That is enough to make the decision on evidence rather than on a thread.