The demo was cheap. That is part of what made it convincing: a working agent, a real task completed end to end, and an API bill so small nobody thought to mention it. Then the same agent went to production, and the first full month's invoice started a very different conversation.
If this happened to your team, nothing went wrong, exactly. A demo and a production deployment are economically different objects that happen to share code. The demo was not a preview of the production bill — it was a best-case sample of one, and every structural force in agentic workloads pushes the production number away from it.
A demo run is systematically unrepresentative in ways that all point the same direction:
It runs the happy path — a task chosen because it works, on inputs chosen because they're clean. It runs once, not thousands of times against the long tail of real inputs. It runs short: a handful of steps, a small context, a quick finish. And it is observed: if it stalls or wanders, someone stops it, and the aborted attempt doesn't make it into anyone's mental cost model.
None of these conditions survive contact with production. The cost structure that emerges there is driven by mechanisms the demo never exercised.
The loop re-reads its own history. An agent works iteratively: plan, call a tool, read the result, decide, repeat. On each iteration, the model is typically fed the accumulated context — instructions, prior steps, tool outputs — so far. Input token consumption per step therefore grows as the run gets longer, and the total cost of a run grows faster than linearly with its step count. A twenty-step run is not twice a ten-step run; it is worse, because its later steps are its most expensive ones. Prompt caching, where the workload can exploit it, blunts this considerably — but cached reads and cache writes are billed at their own rates, so caching changes the arithmetic rather than abolishing it.
Tool calls multiply model calls. Each tool invocation typically means at least one more model round-trip — deciding to call, then interpreting the result. An agent that consults five tools has quietly turned one user request into a conversation many times that size. In the demo, the tools worked on the first try. In production, they time out, return errors, and get retried — and every retry re-runs its surrounding reasoning too.
Failed runs are billed like successful ones. The provider bills for tokens processed, not tasks accomplished. A run that wanders, hits a loop limit, and gets abandoned costs real money — often more than a successful run, since failure frequently takes the scenic route. Demo economics never price this in, because demos that fail don't get counted.
Retries and fallbacks stack silently. Production systems wrap model calls in retry logic; agent frameworks add their own recovery behavior on top. A transient error can multiply the token cost of a single step several times over without any of it being visible in application-level metrics.
The long tail dominates. Across many runs, cost is rarely distributed evenly. A minority of runs — pathological inputs, tool failure cascades, near-loops — can account for a disproportionate share of total spend. The demo, by construction, sampled from the cheap majority. The bill is written by the expensive minority.
Each mechanism above is individually well known to the engineers running the system. What turns them into a business problem is that the invoice aggregates them all away. The provider bills by tokens per model per day — not per agent, per workflow, or per customer. The bill tells you the burn is real; it cannot tell you which loop is burning.
So when the production invoice surprises, the conversation stalls in a specific way: engineering explains, correctly, that agents are just expensive; finance asks, reasonably, which agents, which customers, what changed since last month — and the room discovers that answering requires a grain of visibility nobody built. The gap between "the bill is big" and "here is exactly where it goes and why it moved" is where trust erodes, budgets get frozen, and AI features get paused on instinct rather than data.
Instrument runs, not just requests. The unit that matters economically is the agent run — one task attempt, end to end. Tag every model call and tool call with a run identifier, so cost can be rolled up per run, per workflow, per customer. Without this, every later question is unanswerable.
Track the distribution, not the average. Watch cost per run at the tails, and track failure cost as its own line: what share of spend went to runs that produced nothing? These two views expose the expensive minority that averages hide — and they are where the fixes with real payback live: step caps, loop detection, context pruning, caching, cheaper models for cheaper decisions.
Reconcile the rollup to the bill. A per-run cost view priced from a rate sheet is an estimate, with all the drift that implies. Tie the rollup to the invoice: your per-run figures should sum to totals that match what the provider actually charges, and the reconciliation should be checked, not assumed.
Be honest about the boundary. One caveat belongs in every per-agent cost report, including any built on our engine: invoice reconciliation verifies bucket totals — spend per model per day ties to the bill. How that verified total splits across runs inside a bucket — the attribution layer — depends entirely on the quality of your run-level telemetry and tagging. The bucket can tie out perfectly while the split within it is only as good as your instrumentation. Report both layers, and say which is which.
Do the arithmetic before scale does it for you: the demo told you the agent works; only run-level cost visibility, tied to the invoice, tells you what it costs to work.
ToTheCent's role in this story is the anchor at the bottom: deterministic reconciliation of the provider bill, so that every per-run and per-customer view your team builds rolls up to a total someone has actually verified against the invoice.