The self-hosting business case is almost always argued on privacy and justified on cost per
token. Both are usually the wrong argument. The privacy question is frequently better answered
by a contract than by hardware, and the cost calculation quietly assumes a level of GPU utilisation that
bursty business traffic never reaches. Strip both away and what remains is a genuine engineering
decision — just not the one the business case was written about.
The arithmetic everyone quotes
Take a GPU’s hourly cost, divide by its theoretical maximum throughput, and self-hosting looks
spectacularly cheap next to a frontier API. The number is real. The assumptions behind it are the
problem: high sustained utilisation, ideal batching, and no engineering cost at all.
Business traffic is rarely so obliging. Demand arrives in a working-hours pattern with peaks around
month-end and product launches, and your hardware bill continues through the night whether anything is
running or not. Self-hosting converts a variable cost into a capacity cost. That is a good trade at high
sustained volume and a poor one at low or spiky volume — which describes most first AI deployments.
The comparison almost nobody makes
Here is the part that changes the conclusion. The honest comparison is usually not self-hosted
open weights versus a closed frontier API. It is self-hosted open weights versus a specialist
provider serving the same open model.
That provider pools demand across many customers, so their hardware stays busy in the hours yours would
be idle. At low or variable utilisation they will frequently beat you on the same weights, running the
same architecture, producing the same outputs. Once you make that comparison, a large share of
self-hosting business cases stop clearing the bar — not because the arithmetic was wrong, but because it
was aimed at the wrong opponent.
And then there are the people. Drivers, inference software, upgrades, monitoring, security, capacity
planning, backups, on-call rota, and re-running your evaluation set every time a model version changes.
None of that appears in a cost-per-token figure, and all of it appears in a payroll.
The distinction we use with clients
It fits in a sentence: the economic case for self-hosting is mainly a utilisation question; the
strategic case is a sovereignty question. Keeping those separate is what stops the conversation
going in circles.
The strategic case is real, and it does not depend on winning the cost argument. Offline or air-gapped
operation. Client mandates or contractual rules that prohibit the data reaching an external processor.
Egress restrictions. Export controls. Continuity requirements where an interruption is unacceptable.
Control of logs and weights. Any one of these can justify self-hosting even when an API is
cheaper — and saying so plainly is more persuasive than a spreadsheet that does not survive
scrutiny.
June 2026 gave the continuity argument an unusually concrete example. On 12 June, US export controls
forced Anthropic to suspend access to two frontier models while it could not reliably verify user
nationality. The controls were lifted on 30 June and service returned on 1 July. Three weeks. Not a
catastrophe — but a demonstration that access to a closed frontier service can change because of a legal
or geopolitical decision that appears nowhere in your contract. Weights running on infrastructure you
control cannot be withdrawn the same way.
The right response is not “self-host everything”. It is that a load-bearing AI dependency deserves the
same continuity analysis as any other critical supplier, including a tested fallback where the
consequence justifies one.
Four words that are not synonyms
Most of the confusion in these conversations comes from four terms used interchangeably when they mean
different things. Our chapter on deployment separates them:
- Data residency — where data is physically processed or stored.
- Localisation — a policy or legal requirement that it remain in a defined territory.
- Jurisdiction — which legal regimes and government access powers can reach the
provider or the data. - Sovereignty — how far you can operate, govern and continue the capability under
controls you own rather than controls a supplier or foreign government can change.
A workload can have EU residency without being sovereign. It can also be sovereign without sitting in
your own building. Define which of the four you actually require before choosing a hosting label, because
the four have very different price tags.
One more distinction worth keeping
Open weight does not mean self-hosted. You can call a hosted API that serves a downloadable open model,
and that is a different decision — with a different risk profile — from running the same weights yourself.
Conflating the two is how a sovereignty requirement ends up satisfied on paper by a third-party API.
And if you do self-host, sovereignty does not stop at the weights. Record where they came from, the
licence, the checksum and the version. Pin container images and packages. Control who can update the
inference server. A system that downloads arbitrary models or packages from the internet is not sovereign
however local the GPU is. The full argument, with the deployment comparison table and the cases where
self-hosting genuinely wins, is in Understanding AI in 2026.