The $1.20 Problem: Why Agentic AI Workflows Cost 30x More Than Chat

I spent last week looking at the math behind Uber's AI budget blowup. The headlines focus on the $1,200 single-session cost and the 5,000 engineers who burned the annual budget in four months. But the structural problem is something quieter and more general: agentic workflows cost roughly 30x more per completed task than a chatbot query, and almost nobody budgets for that before they deploy.

EY pegs the number at about $0.04 per standard chatbot interaction and $1.20 per orchestrated agentic workflow. That is not a vendor estimate. It is based on observed production data across enterprise deployments. The multiplier comes from the architecture: an agent does not fire one request. It plans, calls tools, reads output, reasons again, calls another tool, iterates, and verifies. A task that produces a single response in chat can trigger 10 to 20 LLM calls in an agent.

The gap between $0.04 and $1.20 is where budgets disappear.

Where the 30x multiplier comes from

Three structural factors compound agentic cost over chat.

Turn count. A chatbot fires one or two inference calls per user message. An agentic workflow, say "find the bug in this PR and write a fix", can run 10 to 20 turns internally. Each turn costs input tokens (system prompt, tool definitions, accumulated context) plus output tokens (reasoning chains, tool calls, responses). Gartner's March 2026 analysis measured a 5x to 30x token multiplier for agentic workflows over traditional generative AI. At 15 turns per task, the cost is not 15x the chat cost. It is more, because each turn carries the accumulated conversation history.

Context accumulation. Every turn appends the previous output to the conversation. By turn 10, the agent is paying full input price for a context window that has grown 10x since the first turn. Prompt caching helps on the system prompt prefix, but the dynamic content (tool results, user context, intermediate reasoning) grows every turn and is not cacheable. This is why a 15-turn agent conversation with a 12,000-token prefix on Claude Sonnet can cost $0.06 to $0.12 in input alone, compared to a single chat turn at $0.003.

Tool output bloat. Agents call tools that return data. A code search tool returns a file tree. A web fetch returns a page. A database query returns rows. Those results get appended to the conversation and resent on every subsequent turn. If an agent runs three tool calls per turn across 10 turns, that is 30 tool outputs in the final context. Each output is input-priced on every subsequent turn. Teams that measure this find tool outputs account for 40% to 60% of the input token cost of an average agent session.

Why the per-token price fallacy hits agents hardest

The standard objection is "but token prices are falling 10x per year." That is true for a fixed capability level. It is irrelevant for agent costs, because agents do not consume a fixed number of tokens per task. They consume whatever the workflow requires.

The Capital and Compute analysis of the price collapse shows the distinction clearly. The cheapest GPT-4-class model fell from $60 to $0.20 per million output tokens, a 300x drop. But the frontier flagship price only halved, from $60 to $30. The per-token price of yesterday's frontier falls fast. The per-task cost of an agent running today's frontier models does not, because the agent uses more tokens per task as models get better.

Reasoning models make this worse. A 2026 reasoning model emits internal chain-of-thought tokens, sometimes 10,000 tokens or more, before producing the final answer. The cheaper-per-token model finishes the same task at higher total cost because the token count per task exploded. This is not a bug. It is the architecture of modern reasoning. But it is not priced into most budgets.

Three structural controls that work

I have been through enough production deployments now to have a short list of what actually moves the number on agent costs. These are not theoretical. They are applied by teams running agentic workloads at scale.

1. Compact conversation history. The highest-leverage single change in an agent loop is to stop sending the full history on every turn. After N turns, rewrite the accumulated context into a shorter summary. Claude can do this itself if prompted. A 40,000-token turn that compacts to 5,000 tokens saves 35,000 tokens of input on every subsequent read. In a 15-turn agent, that is roughly 500,000 tokens of saved input per session. On 10,000 sessions a month, it is the difference between $800 and $100 in input cost on Sonnet.

2. Exclude tool outputs from the cached prefix. Tool results are dynamic. Every different result invalidates the cache and triggers a cache write at 1.25x the base rate. Move tool outputs after the last cache breakpoint. Tag only the static tool definitions, the schema rather than the invocation results, as cacheable. This one change recovers 40% to 60% of cached input efficiency on most agent architectures I have measured.

3. Route at session granularity, not per turn. Prompt caching requires routing identical prefixes to the same physical inference machine. A router that sends some turns to Haiku and others to Sonnet writes the same system prompt to two cache namespaces, paying the write premium on both, and losing the cache on both. The fix is counterintuitive: pick one model for the whole agent session and stay on it. The cache amortises across the session's turns. The saving from a consistent cache hit rate (70%+) on the static prefix outweighs the marginal cost of running a few extra Haiku-tier turns on Sonnet.

What happens when you measure

The teams that manage agent costs well share one pattern I keep seeing: they measure per-session cost before they optimise it. Not per-token cost, not total monthly spend. Per session. The question is not "how much did we spend on API calls?" It is "what did each agent session cost, and was it worth that?"

Cost was built for that question. It wraps your clients, attributes every call to a route, and surfaces the per-feature and per-session cost. When you can answer "this agent session cost $0.40 and produced a resolved support ticket that used to cost $4.00 in human time," you have the data to fund more agentic workflows. When you cannot answer it, you are guessing whether the $1.20 per task is making money or burning it.

The Uber story is not about agents being too expensive. It is about deploying them without per-session cost visibility and discovering the total when the bill arrives. That is a fixable problem. The fix starts with measuring per-session cost before you scale.

What is your per-agent-session cost right now? If you do not know, that is the place to start.