Yesterday I gave a talk at a client about running language models on your own hardware. The slides that drew the most questions were not about capability. They were about what one ordinary afternoon of work actually costs, so here they are as a post.

The afternoon in question: Friday 2026-09-11, the production H100 we run at Trail Openers in UpCloud's Helsinki data centre, Qwen3.8-27B-INT4 under vLLM, serving agent-driven coding work. Not a demo, a normal workday. Seven hours: 1.10 billion input tokens presented to the model, 3.24 million generated, 3.77 kWh, prefix-cache hit rate 97.5%. Cost: 12,53 €, because the machine rents at 1,79 €/h and a fixed-price card costs the same busy or idle.

Two numbers in that paragraph explain everything that follows. Agentic coding is input-heavy in a ratio of roughly 380:1 - the agent reads a lot of code and writes a small diff. And of that billion-token firehose, only 27.5 million tokens were actually computed. The rest came from the prefix cache: the same conversation history, resent every turn, recognised instead of recomputed.

The same afternoon, bought from an API

Take the exact same token volumes (27.5M new input, 1 077M cache reads, 3.24M output) and price them at published rates (read 13.9.2026, 1 € = 1,09 $):

EndpointPricing (new input · cache read · output, per M)Afternoonvs own
Anthropic Claude Opus 56,25 $ · 0,50 $ · 25 $726 €58x
Qwen3.8-27B, OVHcloud (EU)0,40 € · no cache price · 2,70 €450 €36x
Qwen3.8-27B, cheapest list input (Darkbloom)0,15 $ · no cache price · 2,00 $158 €13x
Qwen3.8-27B, cheapest for this load (Chutes)0,32 $ · 0,032 $ · 2,50 $47 €3,8x
Own H100, Helsinki1,79 €/h × 7 h12,53 €-

The comparison people expect is the first row against the last: 58x. The comparison worth learning from is the middle of the table. Darkbloom has the cheapest input price on the list and no cache pricing; Chutes charges twice the list price and offers cache reads at 0,032 $. On this workload the "cheap" provider costs over three times more. The bill is decided by the price of a cache-read token, not by the input list price. Once you know the workload is 380:1 input-heavy and nearly all of that input repeats, the pricing page reads completely differently: the cache-read column is the price, everything else is footnotes.

The honest caveats, because they were on the slides too

The 97.5% hit rate is measured on our vLLM endpoint and assumed for the API columns. Anthropic's cache expires in five minutes and behaves differently; nobody has measured our workload against it. The own-machine figure excludes the maintenance work, which is real. And one more, the one I insist on saying out loud: our card was cheapest because it is mostly idle on our workload shape, median concurrency 0.6 over 21 production days. Per actually computed token our cost is about 0,13 €/M, which is list-price class - a provider who keeps their GPUs full produces a token cheaper than one card ever will. The fixed 1,79 €/h is not magic efficiency. It is a fixed cost meeting a cache-friendly workload.

Over those 21 days the picture holds at scale: 26.4 billion tokens processed for 866 € of machine time, against roughly 16 700 € priced on Claude Sonnet 5 rates. Same mechanism, bigger window.

So I'd put it this way: the per-token price war is real, and on raw computed tokens the APIs are competitive with a self-hosted card. What you are actually buying with your own machine is a different thing: a fixed cost ceiling, EU data residency, and a cache that belongs to you and never expires on a five-minute timer. Whether that is worth the ops work depends entirely on how your workload shapes up.

Mine, apparently, shapes up to 12,53 € an afternoon. The talk's capability and energy slides might be worth their own posts too...