We spent a morning trying to establish which open-weight models are currently the strongest, and gave up.
Not because the information is hard to find — because there is too much of it and it disagrees with itself. Eight reference articles published within weeks of each other gave different version numbers for the same model families and, in several cases, different licenses for the same model. One source listed a flagship model’s license as MIT; another said the license was not yet confirmed. Both were dated within the same fortnight.
That is not a research failure. It is the single most useful thing an executive can know about this market: any ranking of open-weight models is wrong within about a quarter, including the one you are reading.
So this is not a list. It is the part that does not move.
First: "open weight" is not "open source"
The terms are used interchangeably and they are not the same claim.
Open weight means you can download the model parameters and run them on your own infrastructure. That is all it means. It says nothing about what you are permitted to do with them, whether the training data is disclosed, or whether the license would survive scrutiny from your legal team.
Open source, properly used, means the license meets the Open Source Initiative’s definition — no restrictions on field of use, no discrimination between users, freedom to redistribute and modify.
Most of the models being called open source in vendor decks are open weight under a custom license. The distinction is invisible in a demo and decisive at deployment.
The licenses fall into three classes
The specific model-to-license mapping changes constantly. The classes do not.
| Class | What it means | What it obliges you to check |
|---|---|---|
| Permissive (Apache 2.0, MIT) | OSI-approved. Commercial use, modification and redistribution, no royalties. | Little. These are the licenses your counsel already understands. |
| Custom community license | Weights downloadable, commercial use generally permitted, but with conditions attached by the publisher. | Scale thresholds, attribution requirements, field-of-use carve-outs, and territorial exclusions. |
| Source-available / non-production | Weights available for evaluation and research; commercial deployment restricted or requires a separate agreement. | Whether anything you plan to do counts as production. |
The second class is where organizations get caught, because it reads as permissive until someone reads it properly. Conditions that recur across publishers include a monthly-active-user ceiling above which a separate agreement is required, restrictions on using outputs to train competing models, attribution obligations in your product, and — increasingly — rights that differ by the developer’s geography.
That last one is worth flagging on its own. At least one major family currently grants different rights to developers based on where they are established, which turns a model choice into a question about which of your engineering sites is doing the work.
None of this makes custom licenses unusable. It makes them a legal review rather than a download.
Four arguments wearing one word
When somebody in your organization advocates for open weights, they are making one of four arguments. They are frequently not aware of which, and the four have different answers.
Cost.
The claim is that self-hosting is cheaper than paying per token. It becomes true above some volume and is false below it, because self-hosting substitutes a fixed cost — GPUs, or reserved capacity, plus the engineers who keep it running — for a variable one. The break-even depends on your utilization, and utilization is the number nobody forecasts honestly. A cluster sized for peak and idle at night has worse unit economics than the API it replaced. This argument is arithmetic, and it should be settled with arithmetic rather than principle.
Control.
The claim is that you cannot build a durable product on a model that can be deprecated, repriced, or silently changed beneath you. This is the strongest of the four and the least discussed, because it is not about this quarter. A downloaded checkpoint is frozen. It will behave the same way in three years, which matters enormously if you have validated something on top of it — a clinical workflow, a credit decision, an audited process. No commercial API offers that guarantee.
Sovereignty.
The claim is that data must not leave a jurisdiction, a network, or a building. Sometimes this is a genuine regulatory obligation and sometimes it is a preference wearing a regulation’s clothes. Worth separating, because the honest version has an exact citation behind it and the other version does not. Note also that most major API providers now offer regional deployment and zero-retention terms, which addresses a good deal of what sovereignty arguments were originally about.
Avoiding lock-in.
The claim is that open weights preserve optionality. Partly true, and less than it sounds. Your lock-in is rarely in the model. It is in the prompts, the evaluation harness, the retrieval layer, the tool definitions and the accumulated tuning around a specific model’s behavior. Switching between open models is not obviously cheaper than switching between APIs. If optionality is the goal, the investment is in a portable evaluation suite, not in downloadable weights.
The thing that actually decides it
Every serious comparison of these models converges on the same advice, which is telling given how little else they agree on: choose the exact checkpoint and license first, then validate on your own tasks with your own evaluation.
Published benchmarks tell you how a model performs on published benchmarks. Some of them are vendor-reported. Even the independent ones are measuring general capability, and your use case is not general — it is a specific document type, a specific tone, a specific set of edge cases that matter to your business and to nobody else.
Which means the durable asset is not the model. It is the evaluation. An organization with a private eval covering its actual tasks can assess a new model in days and switch when the economics change. An organization without one is permanently dependent on other people’s leaderboards, which — as our morning demonstrated — do not agree.
The wrong axis
The open-versus-closed framing is the wrong axis and it produces bad meetings. The real questions are whether you need a frozen artifact you can validate against, whether your volume clears the self-hosting break-even, whether you have a genuine jurisdictional obligation, and whether anyone has read the license.
Most enterprises will end up running both, and the ones that do it well will be the ones who invested in evaluation rather than in conviction.
One practical rule for the meantime: no model goes into production on the strength of its family name. Licenses differ between checkpoints within the same family, and they change between releases. The thing you are agreeing to is attached to the specific checkpoint you downloaded, on the day you downloaded it.
A note on sourcing: this piece deliberately names no models, versions or benchmark results. Reference material surveyed in September 2026 gave conflicting version numbers and conflicting license terms for the same model families within the same publication window, and we could not verify specific model-to-license pairings against primary sources at the time of writing. License classes, the open-weight versus open-source distinction, and the conditions described above are general and stable; the mapping of any individual model to any individual license must be checked against the publisher’s own model card on the day of deployment.
Related Reading
Independent. No sponsorships. Unsubscribe anytime.