Open-Weight Models and the New Enterprise Calculus
The choice between proprietary API models and open-weight models you host yourself has become a real strategic decision, not an ideological one. Here's the calculus that actually matters.
- 01Open-weight models have closed enough of the capability gap that the choice is now about control, cost-at-scale, and data residency — not raw quality alone.
- 02The true cost of self-hosting is operational, not licensing: you trade a per-token bill for an infrastructure and expertise burden.
- 03The smart pattern is increasingly hybrid — open models where control and volume matter, frontier APIs where peak capability does.

A few years ago the choice between a proprietary API model and an open-weight model you run yourself was, for most serious enterprise work, not really a choice at all — the frontier proprietary models were so far ahead that anything else was a toy. That's no longer true. Open-weight models have closed enough of the gap on a wide range of business tasks that the decision has become a genuine strategic calculus. Getting that calculus right is now a real lever on cost, control and risk.
What actually changed
The headline is that capability is no longer the automatic tiebreaker. On many practical enterprise tasks — classification, extraction, summarisation, routine generation, retrieval-augmented question answering — strong open-weight models are good enough that the marginal quality difference versus a frontier API doesn't justify ignoring everything else about the decision. The very hardest reasoning tasks may still favour the frontier, but a large share of real business workloads aren't the very hardest reasoning tasks.
That shift moves the decision from "which is better" to "which fits," and "fits" is a function of three things that have nothing to do with leaderboard scores.
The three real factors
Control. An open-weight model you host is a model you can fine-tune freely, pin to a known version, modify, and run without depending on a vendor's roadmap, rate limits, or deprecation schedule. For some organisations that control is a nice-to-have; for others — those building products on top of a model, or those who've been burned by a sudden model deprecation forcing an unplanned migration — it's the whole point. With a proprietary API, the model can change underneath you, and your only recourse is to re-validate everything.
Cost at scale. The cost curves cross over at volume. Proprietary APIs are cheap to start and expensive at scale; self-hosting is expensive to start (you're paying for infrastructure and expertise whether you send one request or a million) and can be cheaper per unit at high, steady volume. If your usage is spiky or low, the API almost always wins on cost. If it's high and predictable, self-hosting can pay for itself — if you can actually run it well.
Data residency and governance. For organisations in regulated industries or jurisdictions with strict data rules, the ability to keep all inference inside their own boundary — no data leaving for a third-party API — can be a hard requirement rather than a preference. For these buyers, open-weight self-hosting isn't a cost optimisation; it's the only compliant option.
The cost that isn't in the licence
The most common mistake in this calculus is treating "open" as "free." Open-weight models have no licensing fee, but the real cost of self-hosting is operational, and it's substantial. You're taking on GPU infrastructure (to buy or rent and to keep utilised), the engineering expertise to serve models efficiently, the work of optimisation and scaling, and the ongoing burden of keeping it all running. You're trading a clean per-token bill you can forecast for a lumpy infrastructure-and-headcount cost you have to manage.
For an organisation without that expertise in-house, the operational burden frequently dwarfs whatever licensing savings the spreadsheet promised. "We'll just host the open model" has sunk plenty of projects whose teams underestimated what "host" actually entailed.
The hybrid endgame
The sophisticated pattern emerging isn't open or proprietary — it's both, routed by fit. Open-weight models handle the high-volume, control-sensitive, data-resident workloads where their economics and governance shine. Frontier APIs handle the spiky, peak-capability tasks where their quality justifies the price and the lack of operational burden is worth paying for. A routing layer sends each request to the cheapest model that can do the job acceptably, with evals deciding where the line sits.
That hybrid posture also happens to be the most resilient one: it keeps you from betting the business on any single vendor or model, and it turns the whole proprietary-versus-open question from a one-time religious war into a dial you can tune as the models, the prices and your own volumes change. The right answer isn't a side — it's an architecture that lets you keep choosing.
Ask Relay — he reads every question himself and replies personally by email.
