What an agent costs, and where the money actually goes

Blended token prices across frontier models fell roughly 67% in a year, from about $18.40 per million tokens in early 2025 to around $6.07 in early 2026. The per-token cost of intelligence is down something like 98% since the start of 2024.

Over the same period, 73% of enterprises exceeded their original AI cost projections. One survey puts the figure at 96%. Uber's engineering organisation went from 32% adoption of an agentic coding tool to 84% between December and March, and had consumed its entire annual AI budget by April.

Prices collapsed. Bills rose. That is not a contradiction and it is not a pricing problem.

Agentic workloads consume between five and thirty times more tokens per task than a chatbot query, and the multiplication compounds rather than adding: a ten-turn agent session costs on the order of fifty times a single call, not ten. Almost every business case is written against cost per prompt, and the only unit that means anything is cost per completed task.

The mechanism nobody models

Here is the calculation that explains most budget overruns, and it takes one paragraph.

A conversational turn sends the whole history. Turn one sends the system prompt plus your question. Turn two sends the system prompt, your question, the model's answer, and your next question. Turn three sends all of that plus two more messages. Input tokens on turn N are roughly proportional to N, so total input across a session is proportional to N squared rather than to N.

Ten turns is not ten times one turn. It is closer to fifty times.

For a chat interface this is bounded, because conversations are short and people leave. For an agent it is not, because an agent's turns are tool calls it makes to itself. A single user request that triggers fifteen internal steps has run a fifteen-turn conversation, and the user saw one input box.

Three things make it worse in practice.

Tool output is verbose. A tool returns a JSON payload, a file listing, a stack trace, a page of documentation. All of it enters the context and all of it is re-sent on every subsequent step.

Reasoning tokens count. Models that think before answering generate tokens you are billed for and frequently do not see. On a multi-step task that thinking happens at every step.

System prompts are large. Coding agents in particular ship substantial instructions and tool definitions before your request is read at all. Published comparisons put one popular tool at around 33,000 tokens of preamble against another at around 7,000, which is a four-fold difference in the fixed cost of every single call before any work happens.

Coding agents pay all four bills at once: large context, long loops, verbose tool output, and reasoning by default. That is why they are the category where budgets go first.

The Uber case, and why it is typical rather than exceptional

The most instructive public example is worth walking through, because the shape recurs.

An agentic coding tool went from 32% adoption to 84% across a five-thousand-engineer organisation in roughly three months. By the fourth month the annual AI budget was gone. Monthly API cost per engineer ran between five hundred and two thousand dollars.

Nothing went wrong in the usual sense. No runaway loop, no misconfiguration, no vendor overcharge. Engineers found the tool useful and used it more, which is what successful adoption looks like. The budget was built on a pilot population and a pilot usage rate, and both moved by a factor of several while the per-engineer cost stayed roughly constant.

Three lessons generalise.

Adoption is a cost multiplier and it is usually the largest one. A tool that costs a thousand dollars per engineer per month is cheap at 5% adoption and transformative to a budget at 84%. Budget models built during pilots almost always hold adoption fixed, because during a pilot it is fixed.

Usefulness and cost are the same signal. A tool nobody uses costs nothing. The cost curve and the value curve are the same curve, which makes "our AI spend is growing fast" an ambiguous statement rather than a bad one, and means the response should be unit economics rather than a cap on adoption.

The budget cycle and the adoption cycle run at different speeds. Annual budgets set against quarterly adoption changes will be wrong, and the direction of the error is predictable. Monthly reforecasting against actual usage is unglamorous and is the only thing that prevents this.

The reason the case matters is that it is not a story about carelessness. It is what happens when something works.

What the estimate leaves out

The number in the business case is inference on successful runs. Five things sit outside it, and together they frequently exceed it.

Failed runs. An agent that fails at step twelve of fifteen consumed the tokens for twelve steps and produced nothing. At a 15% failure rate on a long workflow, a substantial share of total spend buys no output at all. Per-call estimates assume calls succeed.

Retries. Failure handling usually means retrying, which means paying again, sometimes from the start. A workflow with retry logic and no cap can spend an unbounded amount on one request, and this is the failure mode that produces the invoice nobody can explain.

Human review. Almost every production agent has a person checking some share of the output. That person's time is frequently the largest line item, and it is almost never in the original case, because the case assumed the agent replaced the person rather than requiring one.

Evaluation and monitoring. Scoring production traffic with a judge model costs inference. Tracing costs storage, and full traces including prompts and retrieved context are large. Both are ongoing, and both were absent from the pilot where a developer watched the output by hand.

Model version churn. Providers update models under stable names and deprecate versions. Each change means re-evaluating, sometimes re-tuning prompts, occasionally rebuilding a workflow that depended on a behaviour that moved. This is a standing engineering cost with no line item anywhere.

Cost per completed task

The unit shift is the most useful single change available, and it follows directly from the arithmetic above.

Cost per token is a supplier metric. Cost per call is closer but still wrong, because a request that fails costs money and delivers nothing. Cost per completed task is the only figure that maps onto what the business is buying, and it is computed as total spend divided by successful outcomes rather than by attempts.

The gap between the two is the failure rate, and it is multiplicative. A workflow at 60% end-to-end completion has a cost per completed task roughly 1.7 times its cost per attempt. At 36% completion, which is what a twenty-step workflow at 95% per-step reliability produces, the multiplier is nearly three.

This reframes reliability work as cost work. Moving per-step reliability from 95% to 98% on a twenty-step workflow takes completion from 36% to 67%, which cuts cost per completed task almost in half without touching a single pricing lever. Teams treat reliability and cost as separate workstreams; they are the same workstream measured differently.

For reference points, published figures put a single coding task somewhere between three cents and thirteen cents depending on model and reasoning settings, an unconstrained agent on a substantial software engineering task at five to eight dollars in API fees, and enterprise coding-agent deployments averaging around thirteen dollars per developer per active day. Customer support resolution lands at roughly one to six dollars per ticket. Treat all of these as order-of-magnitude anchors rather than estimates for your workload, because the variance across implementations exceeds the variance across models.

The architectural decision that costs 87%

An analysis of 2.4 billion enterprise API calls in early 2026 found organisations running a tiered model architecture at a median blended cost of $2.31 per million tokens. Organisations routing everything to frontier models paid $18.40.

That is an eight-fold difference, produced by one decision usually made at the start of a project and never revisited.

The reasoning behind it is not complicated. Frontier models are priced for frontier work: multi-step reasoning, long-context synthesis, judgement under real ambiguity. Classification, extraction, intent detection, summarisation and routine routing make up the majority of steps in most agentic workflows and do not require frontier capability. Published estimates suggest smaller models can substitute in something like 80% of agent subtasks.

Routing is the highest-leverage lever available and it is architectural rather than operational, which is why it is rarely retrofitted. A workflow built on a single model call throughout is much harder to tier afterwards than one built with a routing layer from the beginning, even if that layer initially routes everything to the same place.

The levers, in order of what they return

Prompt caching. Cached input costs roughly a tenth of fresh input at major providers. Long system prompts, tool definitions and stable retrieved documents should never be re-billed at full rate. Cache hit rates above 70% are achievable for agent workloads and cut bills by half or more. The requirement is ordering prompts so the stable prefix comes first, which is a code change rather than a purchase.

Model routing. The 87% gap above. Cheap models for the routine majority, frontier for the hard minority, with a classifier deciding. The classifier is itself imperfect and the economics still favour it substantially.

Context discipline. Every token in the prompt is billed on every step it survives. Summarising between steps, scoping retrieval tightly, and dropping tool output that is no longer needed all attack the quadratic term directly, which is where the money is.

Output control. Capping response length and constraining format. Verbose output is a silent multiplier, both directly and because it enters the context for every subsequent step.

Batch processing. Major providers discount asynchronous work by around 50%. Anything not interactive should be there. Controlled benchmarks show batching 32 requests reducing per-token cost by around 85% while adding roughly 20% latency, which is an excellent trade for work nobody is waiting on.

Hard budget caps. Per-session and per-workflow spend limits enforced at a gateway, not observed on a dashboard. An agent loop without a ceiling will find one eventually, and it will be an invoice.

Semantic caching. Serving cached results for semantically similar rather than byte-identical queries. Reported to reduce call volume by 30 to 50% when paired with routing, and it carries a correctness risk that ordinary caching does not, since "similar enough" is a judgement.

A worked model you can run

Abstract advice is easy to agree with and hard to act on, so here is the calculation in full, with numbers you can replace.

Take a support workflow. One user request triggers six internal steps: classify the request, retrieve relevant documents, draft a response, check it against policy, revise, and format.

Naive estimate. Six calls at roughly 2,000 tokens each is 12,000 tokens. At a blended six dollars per million, that is about seven cents per request.

Add the accumulation. Each step carries the prior context. Step one sends 2,000 tokens, step six sends closer to 12,000. Total input is nearer 42,000 tokens than 12,000. The cost is now about twenty-five cents, three and a half times the estimate, and nothing has gone wrong yet.

Add the failure rate. At 95% per step, six steps complete about 74% of the time. Cost per completed request is therefore about thirty-four cents rather than twenty-five.

Add human review. Suppose 20% of completions are reviewed, at three minutes each, by someone costing forty dollars an hour. That is two dollars per reviewed request, or forty cents amortised across all completions. Human review is now larger than the entire inference bill.

Add evaluation. Scoring 5% of traffic with a judge model at roughly the cost of one call adds perhaps one cent.

Running total: about seventy-five cents per completed request, against a seven-cent estimate. Roughly a tenth of it is what the business case measured.

Now apply the levers. Route the classify, check and format steps to a small model at a tenth the price: inference falls by around half. Cache the system prompt and policy documents, which are identical on every call: input cost falls by roughly another third. Summarise between steps three and four to cut the accumulation. Inference lands near eight cents.

Revised total: about fifty cents, of which the human is now eighty percent.

That last line is the useful finding, and it recurs across workloads. Once the obvious inference optimisations are done, the dominant cost is usually the person, which means the next lever is not a pricing decision but a question about which outputs actually need reviewing.

Self-hosting, and when it stops being silly

The break-even for running your own inference against API pricing sits somewhere around five to ten million tokens per day for stable workloads, on published estimates.

Below that, self-hosting is almost always a mistake: you are buying an operations burden to save money you were not spending. Above it, the calculation shifts, particularly for predictable baseload work where utilisation can be kept high. Organisations with existing ML infrastructure teams can push the marginal cost of an additional token toward zero for that baseload, though the fixed costs are substantial and the capability gap against frontier models is real.

The honest framing is that self-hosting trades a variable cost for a fixed cost plus an engineering commitment. That is a good trade at high stable volume and a poor one at low or spiky volume, and the crossover depends far more on your utilisation profile than on the token price.

What to do first

Instrument before optimising. You cannot reduce a cost you cannot attribute. Per-span cost tracking, not per-request, so you know which step is expensive rather than which workflow. This is the first step and it is routinely skipped in favour of tactics.

Audit the multiplier. For each workflow, measure tokens consumed per user-initiated task against tokens for a single equivalent call. Anything above roughly ten times warrants architectural review. Published guidance suggests this audit alone surfaces a large share of waste.

Measure cost per completed task. Total spend over successful outcomes. If you are not tracking failures you are not measuring cost.

Set the caps before you need them. Per-session and per-workflow ceilings, enforced. The cost of setting them is an afternoon; the cost of not having them is discovered at month end.

Then route and cache. In that order, because routing is architectural and caching is configuration, and the architectural change is harder to retrofit.

What is unresolved

Whether falling prices eventually outrun rising consumption. Token costs have fallen dramatically and total spend has risen anyway, because capability improvements enabled workloads that were previously impossible. Whether that continues indefinitely or the consumption curve flattens is open. The pattern resembles Jevons' observation about coal, where efficiency gains increased rather than reduced total use, and whether that analogy holds here is disputed.

Whether small models close the capability gap fast enough. The routing argument depends on smaller models being adequate for the routine majority. That share has been rising and the boundary is not stable, which makes any specific routing configuration a temporary answer rather than a settled architecture.

What the actual price floor is. Current pricing reflects strategic capital and competitive positioning as much as cost of service. Nobody outside the providers knows the margin structure, which means today's prices are not a reliable basis for a three-year projection, in either direction.

The counter-argument

The comparison base is usually favourable and rarely stated. A customer support resolution at one to six dollars against five to twenty-five for a human agent is a real saving, and the cost articles that dominate this topic frequently omit that the alternative was never free. An agent that costs more than expected can still cost less than what it replaced.

Cost is not the constraint for most deployments. The dominant failure mode in agent projects is unclear business value rather than escalating spend, and a team that optimises tokens while never establishing what the workflow is worth has optimised the wrong variable. Cost discipline matters most for workloads that are already delivering.

Much of the published cost advice is sold by people with a product. Routing, caching and observability are all things vendors sell, and the figures circulating for their impact come disproportionately from those vendors. The mechanisms are sound and the magnitudes should be treated as claims.

And falling prices are real. A 67% annual decline is substantial, and an architecture that is expensive today may be affordable in eighteen months without any change on your part. Deferring a workload rather than optimising it is sometimes the correct decision, and it is rarely on the list of options.

The short version

Token prices fell roughly 67% in a year while 73% of enterprises exceeded their AI cost projections, which is not a contradiction. Agentic workloads consume five to thirty times more tokens per task than chatbot queries, and the multiplication compounds: each turn re-sends the accumulated history, so total input scales with the square of turn count. A ten-turn session costs on the order of fifty times a single call, not ten. Since an agent's turns are internal tool calls, a single user request can run a fifteen-turn conversation the user never sees.

Four things worsen it: verbose tool output entering context permanently, reasoning tokens billed at every step, large system prompts charged before any work happens, and long loops. Coding agents pay all four at once, which is why they exhaust budgets first.

Five costs sit outside the estimate entirely. Failed runs, which consume tokens and produce nothing. Retries, which are unbounded without a cap. Human review, frequently the largest line item and almost never in the original case. Evaluation and monitoring as standing costs absent from the pilot. And model version churn, a permanent engineering burden with no line item.

The unit shift matters more than any tactic: cost per completed task, meaning total spend over successful outcomes, rather than cost per token or per call. That reframes reliability as cost work, because moving a twenty-step workflow from 95% to 98% per-step reliability takes completion from 36% to 67% and nearly halves cost per completed task without touching pricing.

The single largest structural decision is model routing. Analysis of 2.4 billion enterprise calls found tiered architectures at a median $2.31 per million tokens against $18.40 for routing everything to frontier models, an eight-fold difference produced by one choice usually made at the start and never revisited.

Common questions

Why are AI costs rising when token prices are falling? Because consumption is rising faster than prices are falling. Blended token prices fell roughly 67% year on year while 73% of enterprises exceeded their cost projections, driven by agentic workloads consuming five to thirty times more tokens per task than chatbot queries and by capability improvements enabling workloads that previously were not attempted at all.

Why does a ten-turn agent session cost fifty times a single call? Because each turn re-sends the entire accumulated history. Input tokens on turn N scale roughly with N, so total input across a session scales with N squared rather than N. Ten turns therefore costs on the order of fifty times one turn rather than ten. This is the single largest hidden cost in agent deployments, and it is invisible in per-call pricing because per-call pricing describes one call.

What does an AI agent actually cost per task? Published anchors: a single coding task runs roughly three to thirteen cents depending on model and reasoning settings; an unconstrained agent on a substantial engineering task reaches five to eight dollars in API fees; enterprise coding-agent deployments average around thirteen dollars per developer per active day; customer support resolution lands near one to six dollars per ticket against five to twenty-five for a human. Treat these as orders of magnitude, since variance across implementations exceeds variance across models.

What is cost per completed task and why does it matter? Total spend divided by successful outcomes rather than by attempts. It matters because failed runs consume tokens and deliver nothing, so cost per attempt understates what you are paying for output. The gap is the failure rate and it is multiplicative: a workflow completing 36% of the time has a cost per completed task nearly three times its cost per attempt.

What is the highest-impact way to reduce agent costs? Model routing, on the evidence. Analysis of 2.4 billion enterprise API calls found tiered architectures at a median $2.31 per million tokens against $18.40 for routing everything to frontier models. Classification, extraction, intent detection and summarisation make up most steps in most workflows and do not need frontier capability. Prompt caching is second, with cached input around a tenth the price of fresh input and hit rates above 70% achievable.

What costs get left out of agent business cases? Five, and together they often exceed the inference estimate. Failed runs that consumed tokens and produced nothing. Retries, unbounded without a cap. Human review of output, frequently the largest line item and rarely in the original case because the case assumed replacement rather than supervision. Evaluation and monitoring as ongoing costs absent from the pilot. And model version churn, since providers update models under stable names and each change means re-evaluating.

When does self-hosting make financial sense? Published break-even estimates sit around five to ten million tokens per day for stable workloads. Below that you are buying an operations burden to save money you were not spending. Above it, particularly for predictable baseload where utilisation stays high, the marginal cost of an additional token can be driven very low. The trade is a variable cost for a fixed cost plus an engineering commitment, and the crossover depends more on your utilisation profile than on token price.

How do I find where the money is going? Instrument before optimising, with per-span rather than per-request cost attribution, so you know which step is expensive rather than which workflow. Then audit the multiplier: tokens per user-initiated task against tokens for a single equivalent call. Anything above roughly ten times warrants architectural review. Then set hard per-session and per-workflow spend caps enforced at a gateway rather than watched on a dashboard, because an agent loop without a ceiling will eventually find one.