Open and Closed Weights

Open weights buy control: data stays inside, the model cannot be de-listed, the version is yours. They do not buy cheapness — you supply the GPUs, the ops, and the concurrency.

"Open-source model" is a term borrowed from software, and it means something very different here. Open-source software hands you the full source code; an open model hands you the weights — a pile of trained numbers. That difference decides what it buys and what it cannot buy.

After reading, you should be able to answer:

• What does open weights actually publish, and what does it withhold?
• What three things does it really buy, and why are none of them about price?
• What is the real cost structure of self-hosting, and why is it not the same as calling an API?
• Under what conditions does self-hosting genuinely hold up, and is there an easier route?

"Open" only delivers part of what the word promises

Three things make up a model: training data, weights, and the training code and recipe.

What the industry calls an "open-source model" generally hands over the second of the three, the weights, and little else. The training data is essentially never released, and the full recipe is usually withheld as well. The more accurate name for it is therefore open weights.

The consequence is this: you can run the model, but you cannot reproduce it, and you have no way to confirm what it was trained on. The biases and gaps covered in the training-data article apply just as much to an open-weight model, and they are harder to check. As for what should qualify as open source for AI, the OSI definition is considerably stricter, and simply releasing weights usually falls short of it. osi-def

A closed model withholds even the weights, leaving you to call an interface. Neither its architecture nor its scale is visible to you, and a vendor swapping the underlying model underneath you may go entirely unnoticed.

So what "open" delivers is the right to run it. Whether that right is worth real money to you depends on the three other things it brings.

What it buys has nothing to do with price

Open weights give you three things, none of them financial:

• Data stays inside your boundary. Inference happens in your own environment, and inputs do not pass through a third party.
• The model cannot be de-listed. The weights you hold will not stop serving one day, and cannot be repriced.
• You set the version. Upgrading is an action you take, not something you discover when the logs start looking different.

Those three are what you are buying. Price is a separate set of books, and it usually does not favor this side.

Put another way, the first question is whether what you lack is control or cheapness. The two answers often point in opposite directions.

Why the self-hosting math goes wrong

The most common error is treating "no API fee" as the same thing as "free."

What actually draws money: compute (bought or rented; a larger model usually occupies several cards), power and hosting, operations staff (deployment, monitoring, incident recovery, version upgrades), and concurrency capacity (the more people online at once, the more redundancy you have to keep in reserve).

What matters is that the bulk of this spending is fixed cost, indifferent to how much you actually consume. An API settles by consumption, so an hour with no requests costs nothing; a self-hosted machine sits there and money drains out of it whether it is working or not.

The conclusion tends to be consistent: while request volume is small, self-hosting's cost per request is startlingly high; only once volume is large enough to spread the fixed cost thin does it stand a chance of paying off. And how large "large enough" actually is usually sits well above the team's first guess.

One more line item that is easy to miss: the capability gap and the cost of keeping pace. An open-weight model generally still trails the leading closed ones, and every new release leaves the evaluation and tuning work on your side; with an API the reverse holds — the vendor completes the upgrade and you inherit the benefit. stanford-ai-index

When self-hosting genuinely makes sense

Any one of these conditions makes self-hosting legitimate.

• Data absolutely cannot leave. An unannounced pricing plan, a raw customer call recording, any regulated personal data — if none of it can leave your environment, this is the only route left. Compliance outweighs every cost argument here, and it is the most legitimate and most common reason.
• A version must be frozen. In a long-horizon delivery or contract, you cannot accept the model's behavior changing quietly one day.
• Volume high enough to amortize fixed costs. Run on the API for a while first, then compute the payback period from real usage. If you cannot compute it, it is not time yet.
• You need to own a fine-tuned variant. If you have tuned on your own data and that variant must stay in your hands, only open weights can give you that.

If none apply, use an API. Stop reading "open source" and "cheaper" as the same thing, and the judgement gets considerably clearer.

The route that skips the machine room

Hand the machines and the operations to someone else and you still keep part of the control: an open-weight model hosted on a cloud platform.

The weights are open, the running of them belongs to the platform, and you settle by actual call volume. The freedom to choose your model survives — the same weights can move to a different host tomorrow without buying hardware again. What you give up is having your data pass through the platform and having your version migration follow its retirement schedule; that is two degrees of control less than running it yourself.

Its place is clear: for a team boxed in by the control problem but nowhere near the volume self-hosting needs, this is a far more practical route than forcing a build-out. But it solves the operational burden, not the data boundary — only self-hosting gives you that.

What this does not imply

It does not imply that open weights are always worse. The gap is narrowing, and on classification and extraction work a competent open-weight model is entirely sufficient. What it does not imply is "so self-hosting is always cheaper" — those are two independent sets of books.

Nor does it imply "so just start with the cheap one." The real cost difference often lies not in the unit price but in how much engineering time you spend bringing a cheap model up to the passing line, and in whether the wrapper layer has to be rebuilt on the next swap. Selection has to weigh three things together: unit price, switching cost, and how it performs on your own cases.

That closes the money. The next chapter asks something more important: which of its answers can you trust. Start from the root — the world it read stops on a certain day.