The Real Cost of Open vs Closed Models

The cost argument for open-weight models is usually made as though the licence fee were the point. It is not. Weights that cost nothing to download still cost money to serve, and the interesting comparison is between total delivered cost per token, not between a price and a zero.

What has changed by August 2026 is that the open tier is no longer the cheap-and-weaker option. It contains some of the strongest models available, and the pricing spread within it is wider than the spread between open and closed.

The prices, side by side

Through hosted APIs, the open-weight tier spans an enormous range. DeepSeek V4 Flash runs around $0.14 in and $0.28 out per million tokens. DeepSeek V4 Pro is around $0.44 and $0.87. GLM-5.2 is around $1.40 and $4.40. Kimi K3 lists $3 in and $15 out, with cached input at $0.30.

That is a factor of more than twenty between the cheapest and dearest models in the same licensing category. Choosing "open" tells you almost nothing about what you will pay; choosing which open model tells you everything.

Against that, the strongest closed models are measured on different leaderboards entirely — Claude Fable 5 Max leads GDPval-AA v2 at 1,815, with GPT-5.6 Sol Max at 1,747.8 — and their pricing is a moving target you should read off the vendor page rather than any article.

The honest summary is that the open tier now covers the whole price range, and the frontier open models are priced like frontier models because that is what they are.

Licences are not all the same

"Open weights" is a marketing category, not a legal one. GLM-5.2 and both DeepSeek V4 variants ship under MIT, which is about as permissive as it gets and imposes no meaningful commercial condition.

Kimi K3 and Kimi K2.6 are not MIT. They carry Moonshot's own terms, and K3's licence includes a revenue threshold that attaches conditions to offering the model as a service. If your business model is reselling inference, that clause is a cost input and you need your lawyer to read it, not a blog post.

Qwen is permissive across most tiers. The practical point is that you cannot infer the licence from the fact that a download link exists, and open weights are not the same thing as open source in either the legal or the practical sense.

For internal use the distinction rarely bites. For anything customer-facing where inference is part of the product, read the actual text before you build on it.

Where open weights genuinely save money

Three cases, and they are narrower than the enthusiasm suggests.

Sustained high volume. Self-hosting converts a variable per-token bill into a fixed capacity bill, which wins above a break-even volume you can compute. Working out that break-even is a half-hour exercise, and most teams discover they are an order of magnitude below it.

Data that cannot leave. When regulation or contract forbids sending content to a third party, the comparison is not open versus closed but open versus not doing it at all. Cost stops being the deciding term.

Small dense models on modest hardware. Qwen 3.6 27B is a dense 27B that runs on a single GPU and posts 77.2% on SWE-bench Verified. A model that fits one accelerator has an operational cost structure a 2.8T-parameter MoE never will.

Where the open case quietly falls apart

Kimi K3's open weights are roughly 1.6TB. That is not a download you serve from a spare machine; it is a multi-node deployment with the networking, monitoring and on-call burden that implies.

Utilisation is the other killer. A rented GPU bills whether or not you send it traffic, so a fleet sized for peak and idle most of the day carries a cost per token far above the sticker arithmetic. Metered APIs charge nothing when nobody is working, which for a team of developers is most hours of the week.

And engineering time is real money. Someone has to own the serving stack, the upgrades, the capacity planning and the 2am page. The local versus API comparison covers where that boundary sits for individual machines.

The cost that only appears later

Switching cost is the term neither side puts on a slide. A closed model reached only through a proprietary API is a dependency you cannot replicate if pricing or availability changes; an open-weight model is one you can always take somewhere else, even if you never do.

That optionality has a value, and it is not zero. It is also not infinite, and paying a large premium per token today to preserve a portability you will never exercise is a poor trade.

The practical hedge is architectural rather than contractual. Keep to an OpenAI-compatible interface, avoid vendor-specific request fields in your core path, and keep a tested fallback configured. Routing and fallbacks covers the mechanics, and the broader open versus closed comparison covers the non-cost dimensions.

The comparison to actually run

Take one representative task from your own workload. Measure input tokens, output tokens and success rate on two or three candidates spanning the price range — something at the $0.14 end, something mid, something frontier.

Then compute cost per successful result, not cost per call. A model at a fifth of the price that needs three attempts is not cheaper, and a frontier model that lands first time is often the budget option in disguise. Benchmarking on your own work covers building that harness in an afternoon.

The decision rule: use hosted open weights by default, because the price range is wide and the licences on the MIT tier impose nothing. Self-host only when a computed break-even, a legal constraint or a latency floor forces it. And treat the licence text as a cost input the moment inference becomes part of what you sell.