Cloud Intelligence™
Your developers want a self-hosted LLM. Your CFO wants the math.
The break-even on self-hosting an LLM is not a team size. It's a spend level — and with real enterprise usage data, it arrives earlier than the pricing pages suggest. Here is the math, from the 3.2x spread in H100 rental prices to the month your API bill outruns a GPU node
This page is also available in Deutsch, Español, Français, Italiano, 日本語, and Português.
This post tells you what your AI stack costs. Attribute tells you which teams and products that cost belongs to.
About Vadim Solovey
Founded DoiT in 2011 and have been here ever since — in every flavor of CTO, co-CEO, and now CEO. I started my career in 1999 building data centers before anyone called it "the cloud," and I've spent the two decades since trying to deliver on what the cloud was actually supposed to be. I still write code most weeks.
My personal pageThe list prices look unbeatable. Claude Code runs $100 to $200 a month on Max plans, or $100 a seat billed annually on Team Premium; Codex sits in the same band. Fifty developers cost $5,000 to $10,000 a month, a fraction of any GPU cluster that could serve them, and the self-hosting argument would end right there.
But those plans carry hard usage caps, and serious usage has stopped being human-shaped. A background agent that reviews every pull request, a nightly codemod sweep across 400 repositories, a CI pipeline that generates and repairs tests: these run on metered pricing (list $3 per million input tokens and $15 per million output for Sonnet 5; $5 and $25 for Opus 5), nobody caps them for you, and the bill scales with ambition, not headcount.
We can put a number on that shift, because it happened to us. Across DoiT's own engineering team, on usage-based Claude Code Enterprise pricing, the average is now about $2,200 per developer per month. Not the ceiling — the average — and not static: it has grown every month as agentic workflows spread, with no plateau in sight. Your number will differ — a team of light users on capped plans really does cost $100 a head, and if that's your team, the subscription wins and you can stop reading — but the direction of the curve is the same everywhere we look. So the real question isn't "should ten developers rent a GPU" — it's at what level of sustained spend a rented node beats a metered API for the work an open-weight model can genuinely handle.
What a node actually costs
GPU pricing is genuinely hard to compare. At the time of writing, an H100 rents on-demand for $3.85 an hour on Nebius, $6.88 on AWS (the single-GPU p5.4xlarge in us-east-1 — the 8-GPU p5.48xlarge is $55.04, exactly eight times that), $10.98 on GCP (a3-highgpu-8g, us-central1), and $12.29 on Azure (ND96isr, East US). That is a 3.2x spread on identical silicon.
And you don't really rent a GPU — you rent a box of eight. Nearly every serious GPU instance ships as an 8-GPU node, so the sizing question is "how many nodes," not "how many GPUs." One node, around the clock for a month:
| $/GPU-hr | Node/month (~730 hrs) | |
|---|---|---|
| Nebius spot | $2.15 | ~$12,600 |
| Nebius on-demand | $3.85 | ~$22,500 |
| AWS on-demand | $6.88 | ~$40,200 |
| GCP on-demand | $10.98 | ~$64,100 |
| Azure on-demand | $12.29 | ~$71,800 |
Same GPUs, same month, $59,000 of difference between the corners of the table. Two adjustments before you anchor on either corner. Commitments narrow the spread: a 1-year AWS reservation brings the node to about $43 an hour (roughly $31,600 a month), Capacity Blocks have recently cleared around $5.20 per GPU-hour, and 3-year hyperscaler commitments can roughly halve on-demand. And the cheap corner has trade-offs: spot can be reclaimed mid-request — and in a capacity-scarce market may simply not be there when you want it — while the low-cost providers lack the ecosystem your platform team already knows. Whether that's worth $30,000 a month is a real conversation, but it should be a conversation, not a default.
Where the line is
Now the two curves can meet. A saturated 8xH100 node serving a 120B-class open-weight model under continuous batching produces several billion output tokens a month — tokens that would bill in the mid tens of thousands of dollars at Sonnet 5 rates, from a node that costs $12,600 to $40,200. The rule of thumb falls out directly: once your usage-based AI spend on work an open-weight model genuinely handles — high-volume, repetitive, evaluable — sustains above roughly the monthly price of a node, self-hosting is cheaper, and the advantage compounds with volume. At $2,200 a developer, that line sits somewhere between seven and eighteen developers.
Before anyone forwards that to a CFO, two honest additions that raise the bar. If you need the availability an API gives you for free, price two nodes, not one: a single replica means a restart takes the assistant down for everyone. And someone has to run it — model serving, quantization, failover, upgrades — so put an engineer's loaded cost inside the comparison, not in a footnote. With both adjustments, the honest line is sustained spend comfortably above the price of two nodes and part of an engineer — which at real usage rates is still only a few dozen developers' worth of agentic workload.
The boundary case that skips the math entirely: if your code or data cannot leave your boundary, self-hosting was never a cost decision, and the break-point is wherever your compliance team says it is.
The team-size sanity check
Team sizes still make the math concrete, as long as you size by concurrency rather than headcount: developers generate in bursts, and at any moment maybe 10 to 20 percent of a team has a request in flight.
Ten developers is two or three concurrent sessions — half a node's capacity at best. The assistant bill at our usage runs ~$22,000 a month against $12,600 to $40,200 for a node the team can't keep busy: roughly a wash, and the subscription is buying a frontier model, so it still wins. Don't self-host at this size unless the data-boundary constraint applies.
Fifty developers is five to ten concurrent sessions — a single 8xH100 node serves the whole team for models up to the 120B class. The assistant bill at real usage is ~$110,000 a month against the same node: three to nine times the metal.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
A hundred developers is two or three nodes, $45,000 to $80,000 a month rented on-demand, against a ~$220,000 assistant bill. This is also where owning hardware enters the frame. An 8xH100 server costs about $280,000; straight-lined over three years that's $7,800 a month, call it $10,000 to $12,000 with power, colo, and operations, so against $40,200 on AWS on-demand the hardware pays for itself inside a year. Be clear with your finance team that this is a pure cash-payback calculation — the three-year straight-line is the depreciation schedule, with no cost of capital or residual-value guess in it. The counter is utilization: that payback assumes the node runs hot around the clock, and a workload that's busy 50 hours a week uses 30 percent of the hours you bought — at which point your effective on-prem rate triples, cloud lets you not pay for nights and weekends, and reserved pricing closes most of the remaining gap. Owning wins when utilization is high and predictable; renting wins when it isn't. The spreadsheet usually says buy; the utilization data usually says rent. Trust the utilization data.
What the premium actually buys
At fifty developers, the gap between the assistant bill and the node is roughly $70,000 to $100,000 a month. That is not just a premium for the label on the model — the metered API bundles resilience you'd otherwise buy as a second node, elasticity you'd otherwise buy as idle headroom, capacity risk carried by someone else, security tooling and support, model upgrades without a hardware refresh, and zero stranded-hardware risk when next year's model wants next year's GPUs. Two more credits: the frontier model solves more problems per attempt — in cost per merged pull request some of the multiple closes, and only your own eval says how much — and token list prices keep falling as lower-cost frontier providers press them, so the API side of this comparison improves on its own in a way a signed GPU commitment doesn't.
The counterweight favors self-hosting exactly where it applies: predictability. Per-developer spend is the volatile side of this ledger — ours has grown every month — while a rented node is a fixed, known number. For the high-volume, evaluable work that belongs on an open-weight model anyway, you're trading an open-ended bill for a flat one. After crediting everything the premium buys, the gap at fifty-plus developers is still wide enough to fund the engineer who runs the node.
What to actually do
The conclusion is a portfolio, not a side:
- Capped seats for light users — at $100 a head, nothing beats them.
- Metered frontier API for the problems that genuinely need frontier quality — pay the premium where the eval says it earns its keep.
- A self-hosted open-weight node for the high-volume, repetitive, evaluable work — starting the day your sustained usage-based spend on that work clears the price of the node (or two nodes plus an engineer, if you're being honest about availability and ops).
- Self-host regardless of cost when the code can't leave your boundary.
With real enterprise usage numbers, most teams cross the self-hosting line earlier than the pricing pages — and the vendors — would suggest.
Run your own numbers
Whichever tier you're in, four inputs dominate the outcome: which model (parameter count sets the GPU floor), quantization (FP8 halves FP16's memory, INT4 halves it again, each with a quality cost), context length (KV cache for long contexts can rival the weights in memory), and concurrency target (it sets replicas, which multiply everything above).
We got tired of rebuilding this spreadsheet for every customer conversation, so we put it on the web: the AI hosting calculator sizes any of ~29 open-weight models against current GPU pricing, pulled from the providers' own pricing APIs on a schedule, next to an on-prem build estimate. Every number above comes from it, and every number on it traces back to a formula or a stated assumption you can argue with.
Prices in this post are point-in-time (August 2026, reference regions named above) and will drift — GPU rents in one direction, token prices most likely in the other. If your team is somewhere between "thread that died" and "three nodes and a colo contract," run your own numbers before either camp wins by default.
