The bill is mostly repetition
Pull apart a large monthly inference invoice and the same pattern shows up almost every time: a small number of workloads account for the overwhelming majority of spend, and those workloads are the least interesting ones you run.
Document extraction. Ticket deflection. Intent classification. The same prompt shape, the same response shape, thousands or millions of times a month. Metered pricing charges full retail for the ten-thousandth identical call exactly as it did for the first.
Three costs hide inside one line item
A per-token price bundles together things that behave very differently as you scale. Separating them is the first useful thing you can do with the invoice.
- Compute: the actual cost of running the model. This falls with utilisation.
- Provider margin: fixed as a percentage, so it grows in absolute terms forever.
- Optionality: you are paying to be able to switch models tomorrow, whether or not you ever will.
Why the curve bends the wrong way
Metered pricing is close to optimal while volume is low and unpredictable. You pay for what you use, and what you use is small. The economics only turn when a workload becomes both large and stable, which is precisely what happens when a feature succeeds.
That produces the uncomfortable property teams notice around the £10k a month mark: every improvement in adoption, containment or automation rate raises the bill. Success is billed as consumption.
What dedicated capacity changes
Provisioned infrastructure inverts the shape. You buy capacity sized to your demand curve rather than paying per call, so the marginal cost of the ten-thousandth identical request approaches zero.
The trade is real and worth stating plainly: you take on utilisation risk. Capacity you do not use is capacity you still pay for. That is why the move only makes sense for workloads with genuine, sustained volume, and why the honest first step is measuring, not migrating.