Open vs Closed — The Economics of Releasing Weights, and the Safety Argument

Why would a company give away weights that cost a fortune to train? The decisive difference between open-weight and open-source, the licence clauses that actually cause incidents, and what each side of the release debate is really claiming — plus the convergence nobody expected. From no prior knowledge.

The car whose hood opens, and the one whose hood is welded shut

Imagine buying a car and finding the hood welded shut: no inspection, no modification, everything through the dealer. That is a closed AI model. With a product like ChatGPT you can put a question into the slot and get an answer back, but you never touch the weights — the pile of numbers the model acquired during training, which is the model.

The other kind opens. Llama, Mistral, Qwen, Gemma, DeepSeek — with these you can download the weight file itself, run it on your own server, and swap parts out by fine-tuning it.

But an openable hood is not the same as published blueprints. Even when you have the weights, the training data and the full training code are usually not disclosed. You can see the engine without learning why it ended up that shape, and that distinction is the foundation of everything that follows.

"Open" comes in three layers

It helps to stop treating disclosure as one switch and think of it as three layers.

In October 2024 the Open Source Initiative published the Open Source AI Definition (OSAID) 1.0, drawing a line: to call yourself open-source AI you need more than weights — you need the training code and sufficient information about the data. Held to that standard, most of what the world calls an "open-source LLM" does not qualify.

So this article calls that whole group open-weight models. The pedantry has a point: in the licensing work we are about to do, that one word carries contractual weight. "It's open source, so we can use it however we like" is exactly the assumption that turns into a terms violation.

Why give it away — fixed cost and marginal cost

The cost structure of a large model is lopsided. Pretraining is one enormous fixed cost; handing the finished weights to one more person costs essentially nothing — a few tens of gigabytes of transfer. It is the classic software shape: a good with near-zero marginal cost.

The conclusion that follows is "giving it away doesn't raise our costs." But that is not a reason to give it away. The reason is an old strategy: commoditise your complement. Make the thing that sits next to your product — the thing customers need alongside it — cheap, and demand for your own product rises.

• For a company that earns money from ads or devices, an LLM is not merchandise; it is a component of the product experience. Having the standard settle on your stack is enough. You never needed to sell the model.
• For a cloud provider, the thing that sells more as models get cheaper is GPU hours.
• For a young model company, giving away small models buys distribution and adoption. Your name lands in developers' hands, and you recoup on larger enterprise models and support.

The closed logic is just as simple. Withhold the weights and what you offer stops being a product and becomes a service. You bill on every use, you can swap the model underneath and customers follow, and competitors cannot clone the insides. You also keep the record of how it was used — which matters later, in the safety argument.

Where the economics flip

Now the buyer's side. Call the API, or run it yourself? The crossover falls out of one division.

$N^{*}$ is the monthly token volume above which self-hosting is cheaper, $C_{\text{fix}}$ is the fixed monthly cost of self-hosting (reserved GPUs, redundancy, the people who operate it), $p_{\text{api}}$ is the API price per token, and $c_{\text{self}}$ is your marginal cost of generating one token yourself (power and occupied GPU time). Read it in words: divide the fixed cost by the per-token price gap and you have your break-even. That is the whole formula.

Equation (1) earns its keep in the field because the denominator is usually smaller than people assume. $c_{\text{self}}$ tends to get computed as if the GPU ran flat out forever; if your real utilisation is 30%, the true cost is more than triple. Shrink the denominator and $N^{*}$ leaps. "Free weights mean it's cheaper" collapses on that single point more often than on anything else. The economics of GPU clouds works through how to estimate it.