Hot take: a trillion-parameter open-weight model is only open if you read the license

Open weights and open source are not the same thing, and a trillion-parameter release is the best reminder I have seen in a while.

Here is what was reported, and nothing more. Mistral released the downloadable weights for Mistral Large 4 at the end of October. Coverage from Let's Data Science and a Real Python weekly roundup both describe it as a roughly 1 trillion parameter mixture-of-experts model, now available to anyone, after a public API preview earlier in the month. Reports differ on the exact active-parameter count, so I will not quote one. The performance claims come from Mistral itself, and I treat them as a starting point for my own testing, not a conclusion.

One detail got less attention than the parameter count. The license is described as a modified version of MIT, and at least one outlet noted it is not quite the same as open source. That distinction decides whether you can build a product on it.

I have shipped enough systems to know why this matters. In a defence deployment I worked on, the model could never leave the building. Nothing was allowed to phone home. In that environment, weights you can download are only half the story. The other half is what you are legally allowed to do with them: fine-tune, redistribute, run inside a customer's network, ship inside a device.

So before anyone celebrates, here is the checklist I run on any open-weight release.

First, read the license end to end. Look for field-of-use limits, revenue thresholds, and rules about derivative models. A modified license means someone changed the standard terms, and you need to know exactly how.

Second, check what you actually get. Weights are not training data, and they are not the training recipe. You can inspect behavior, but you cannot fully reproduce how the model got there.

Third, be honest about the hardware. A model at this scale is not something most teams run on a single box. Open weights give you control, but control still costs memory and engineering time.

Fourth, run your own evaluation. Vendor benchmarks are marketing until you reproduce them on your data. In my hallucination work on Indic languages, the gap between a published score and real behavior on a low-resource language was the whole story.

Why does this matter to me? Because my bias has always been that models should run where the data is: on-device, offline, under your control. Open weights are the precondition for that. But a license with strings attached quietly takes some of that control back.

The practical upside is real. A model like this can act as a teacher. You can distill its behavior into something small enough to deploy at the edge, if, and only if, the license lets you. That is the question I would answer first, before the benchmark question.

I would also keep the weights, the license text, and the exact version you tested in your own storage. Names get reused. Preview builds and final releases can share a name while differing in training, and one of the reports I read made exactly that point. If you cannot say which checkpoint your product runs on, you cannot debug it or audit it.

The industry loves the word open. Production teams should love the word auditable more.

Takeaway: open weights give you the option to control your stack, and the license decides whether you are allowed to use it. Read the second one first.