Per-token pricing is a good deal at low volume. You pay for what you use, you pay nothing when idle, and you never think about capacity. For a prototype or a product with a handful of users, there is no better way to buy inference.
It stops being a good deal at a specific, calculable point. Past that point you are renting elasticity you no longer need, at a premium, forever. The question worth answering is not whether metered billing is good — it is where the crossing lies, and whether your traffic is above it.
For most production backends the answer sits somewhere between 17 and 113 million tokens a month. The spread is wide because it depends on two things: the shape of your traffic and the size of the context window you need. This post works through both.
Two rates, not one
Every metered provider quotes two prices: one for tokens going in, one for tokens coming out. Output is typically five to six times the price of input. Which rate dominates your bill depends entirely on what your product does with the model.
The asymmetry is more extreme than most teams expect. Across the coding-agent traffic we serve, the ratio sits somewhere around seventy tokens read for every one written. An agent spends nearly all of its budget on context — file contents, tool definitions, prior turns — and produces a few hundred tokens of diff at the end. The expensive output rate barely touches the bill.
Most backends do not look like this. Retrieval-augmented pipelines run nearer 10:1. Conversational assistants sit around 3:1. Summarisation and drafting products approach 1:1, where output pricing dominates completely.
At representative metered rates for Qwen3.6-35B of €0.25 per million input and €1.50 per million output tokens, the blended cost per million total tokens varies by a factor of three:
| Traffic shape | Blended €/M tokens | Typical of |
|---|---|---|
| 70:1 | €0.268 | Coding agents, tool-calling |
| 10:1 | €0.364 | RAG, document Q&A |
| 3:1 | €0.563 | Chat assistants |
| 1:1 | €0.875 | Summarisation, drafting |
Any comparison that does not state its assumed shape is not a comparison. Find your row before reading the next table.
The crossing
A Solheim instance costs around €15 a month at a 64k context window and around €30 at 128k. One instance is one request in flight; the window is a separate dial. Dividing the monthly fee by the blended rate gives the volume at which flat pricing becomes the cheaper option:
| Traffic shape | 64k instance (€15) | 128k instance (€30) |
|---|---|---|
| 70:1 | 56M tokens/mo | 112M tokens/mo |
| 10:1 | 41M | 83M |
| 3:1 | 27M | 53M |
| 1:1 | 17M | 34M |
The window matters as much as the traffic shape. A classifier, an extraction pipeline or a support-reply generator has no use for 128k and crosses over at half the volume. Sizing the window to the prompts you actually send is the single largest lever on this table.
Against frontier models the crossing arrives far sooner — a tenth of the volume or less:
| Traffic shape | vs Claude Sonnet 5 | vs Claude Opus 5 |
|---|---|---|
| 70:1 | 10.3M | 6.2M |
| 10:1 | 8.0M | 4.8M |
| 3:1 | 5.4M | 3.3M |
| 1:1 | 3.6M | 2.2M |
Anthropic rates from claude.com/pricing, standard Sonnet 5 and Opus 5 pricing, converted at approximately 0.92. Break-evens measured against the €30 instance.
Most of that difference is model tier rather than billing model, and it should be read that way. Comparing a 35B open-weight model to Opus on price alone proves very little. The honest comparison is the first table: the same class of model, bought two different ways.
What the curve looks like past the crossing
Taking a retrieval-shaped backend at 10:1, running on a 128k window:
| Tokens/month | Solheim | Metered Qwen | Sonnet 5 | Opus 5 |
|---|---|---|---|---|
| 25M | €30 | €9 | €94 | €157 |
| 50M | €30 | €18 | €188 | €314 |
| 83M | €30 | €30 | €312 | €521 |
| 100M | €30 | €36 | €376 | €627 |
| 250M | €30 | €91 | €941 | €1,568 |
| 500M | €30 | €182 | €1,882 | €3,136 |
Eighty-three million tokens a month sounds substantial until it is divided by request size. A backend that justifies a 128k window is, by definition, sending large prompts — call it 60,000 tokens of context per request plus the output it generates. At that size a single request costs a little over two cents on metered pricing, and the crossing arrives at roughly 1,250 requests a month: fifty-seven on a working day, seven an hour.
Context size is the mechanism. The same property that makes a large window necessary — long documents, deep retrieval, extended tool-calling histories — is the property that makes per-token billing expensive, and the two scale together. A backend running comfortably inside 32k needs several times the request volume before it reaches the same crossing.
Why volume is not the whole answer
There is a second finding that changes how the question should be framed.
When we compared the token volumes above against actual engine time on our own hardware, the volume that carries a workload past break-even turned out to occupy a small fraction of the month. Not most of it, not half — a sliver. Hardware is fast, and a month is long.
Monthly token totals are therefore a poor description of what an inference backend actually needs. What constrains a backend is not how many tokens it moves over thirty days but how many requests must be in flight simultaneously. Ten million tokens arriving evenly and ten million arriving in a two-hour window are the same line on a metered invoice and entirely different engineering problems.
This is why capacity here is sold as concurrent requests rather than token bundles. It is the same unit a backend is already sized against when thinking about peak concurrent users, and unlike a monthly quota it corresponds to the thing that actually fails first.
It also means the sizing decision has a clean answer, and it is not "buy for your peak."
The floor is the thing to size
Traffic to a working product decomposes into two parts. There is a floor — the volume served every day, known in advance, varying little week to week. And there is everything above it: launches, front-page links, an enterprise trial that turns out to involve four thousand documents.
The floor is the part worth buying outright. Its size is already known. It will be served tomorrow and the day after, and it will be served next quarter. Buying it through a metered endpoint means paying a premium for the option to scale it down — an option that will never be exercised. That is pure overhead, and it compounds monthly.
What makes this workable is that the floor is not fixed forever, and neither is the instance count:
- Size to median concurrency, not peak. A backend sitting at two concurrent requests through the working day and touching eight at its busiest buys two instances. Peak-sizing a fixed resource is how teams end up paying for idle capacity, and it is not necessary here.
- Move the slider when the traffic moves. A launch month that needs four instances buys four, then drops back. The dial exists precisely because the floor rises and falls, and adjusting it takes seconds rather than a migration.
- Let modest overshoot queue. Beyond the instance count, requests wait rather than return 429s. A brief burst above the floor arrives slightly later instead of failing, which for most backends is the correct trade.
The pattern is the one infrastructure teams settled on for compute a decade ago: reserve the baseload, keep the ability to adjust, and stop paying on-demand rates for the capacity you use every single day. Inference is the same shape of problem and has the same answer.
Three things that come with owning the floor
A fixed cost line. The majority of inference spend becomes a number that can be put in a model and left there. What remains variable is the minority, and it is variable for a good reason.
No incentive to degrade the product. Metered pricing exerts constant quiet pressure toward shorter context, fewer retries and cheaper models on the hot path — optimisations made for the invoice rather than the user. Below the instance count, the marginal request costs nothing.
A jurisdiction that can go in a contract. EU hardware at EU-owned providers, with no US entity in the serving path. For anyone selling into Europe this is a procurement question rather than a preference.
Finding your own number
Two figures answer it. Monthly token total, available from any provider dashboard, gives the row in the break-even table. Median concurrent requests, available from any application metrics, gives the instance count.
For a genuine prototype — a few thousand requests a month, no floor to speak of — metered billing is still the right purchase. Everything else is past the crossing, usually by a wide margin and usually without anyone having checked. A backend serving seven requests an hour on a large context window is already paying more per month for the privilege of a variable invoice than the fixed capacity would cost outright.
That premium does not announce itself. It arrives spread across thirty days of small charges, it grows with the product, and it is invisible until somebody divides the invoice by the token count. Two numbers and five minutes is all it takes to find out which side of the line you are on.