2%. That is roughly how much of an AI feature's true running cost is captured by the one number everyone puts on the slide — the API bill. Take a mid-sized support team clearing eight thousand emails a month. The token cost of having a model take the first pass at all of them is small enough to look like a rounding error beside a single salary, which is precisely why it gets quoted. On a slide, that number closes the deal.
It is also the most misleading figure in the whole business case. Not wrong — the tokens really do cost that little. Just tiny, and quoted as though it were the entire bill. Token spend is the visible tip of the cost. Almost everything that keeps the feature working sits under the waterline, and none of it surfaces until after you have committed.
The token bill is a rounding error
The model call is the one part of an AI feature that is cheap, metered, and predictable. Its price is published and you can look it up in a minute. What you cannot look up is the cost of making that output safe to act on — and that is the part you are actually buying.
Take the eight-thousand-email feature and cost it properly, rather than optimistically.
The tokens, even after real retries and prompts longer than anyone estimated, stay the smallest line on the sheet. Human review of the slice the model can't safely send on its own — about 40% of the volume, ninety seconds an item — costs several times the entire token bill. The evaluation harness, dashboards and drift alerts, amortised across the first year, cost more again. Guardrails and the integration that breaks whenever a vendor changes an endpoint add another line of the same order. Put the sheet together and the tokens account for roughly one part in fifty.
Put another way, the number on the slide is about 2% of what the feature costs to run. The pitch deck quotes the cheapest line and calls it the price.
Add up the parts nobody quotes
Strip the feature down and you are paying for five things the demo never had to buy:
- Evaluation — a labelled test set and a harness that proves the thing still works after every prompt tweak and every model update.
- Guardrails — the validation that catches a confident, fluent, wrong answer before a customer reads it.
- Human review — the share the model can't own, priced in hours, every single month.
- Monitoring and drift detection — knowing quality has slipped before your customers are the ones who tell you.
- Model churn — re-testing the whole feature each time the vendor reprices, deprecates, or quietly "improves" the model underneath you.
None of these is an optional extra. They are the distance between a feature that runs and one that merely ran once, in a demo, on a good day.
The costs that arrive in month three
The cruel part is the timing. The bill you can model up front — tokens, a review rota — is the small, early one. The expensive costs land later, once the novelty has worn off and the real inputs have arrived.
For the feature above, the monthly run-cost roughly tripled between launch and month three, as retries, review volume and an escalation backlog became real.
Quality drifts as the inputs shift, so the review pile grows rather than shrinks. The vendor sunsets the model you built on and hands you ninety days to migrate and re-test. An edge case that never appeared in the pilot starts generating angry tickets, and someone has to be reachable for it at 2am. The running cost only shows its true shape once the feature is carrying real traffic — the same trap that strands most AI pilots short of production.
Budget for the system, not the call
Pricing AI by the API call is like pricing a delivery firm by the cost of petrol: real, easy to measure, and almost silent on what it takes to run the fleet. The unit of cost that matters is not the token but a reliable outcome, held steady month after month while inputs change and models come and go.
That is a less thrilling number than the one on the pricing page, and a far more useful one. It is also knowable in advance, because the line items are predictable if you go looking for them. An AI readiness assessment exists to put a real figure on the review load, the monitoring and the re-testing before you sign off a budget built on the token price alone.
Common questions
What does it actually cost to run an AI feature in production? The token or API cost is usually a small fraction — often under 5% — of the monthly total. The bulk is human review of what the model can't handle alone, evaluation and monitoring, guardrails, and re-testing whenever the model changes. A feature whose token bill looks trivial can sit comfortably inside a running cost fifty times larger.
Why is the API cost such a small part of the total? Because the model call is the one part that is cheap and predictable. Making its output trustworthy — catching the confident-but-wrong answer and proving nothing regressed after an update — is people and engineering, and that is where the money goes.
How do I estimate the real cost before I build? Cost the outcome, not the call. Estimate the share of volume that still needs a human, the evaluation and monitoring you will maintain, and the re-testing each model change forces — then add the tokens last, where they belong.
Price the model and you will be wrong by a factor of fifty. Price the system around it — the reviewing, the watching, the re-testing that never quite stops — and you will be roughly right. The token bill was never the question worth asking. It was just the only one with an easy answer.