Pular para o conteúdo principal

Why AI Agents Burn Tokens (and How to Cap the Bill)

Intermediário

A chat turn costs a fraction of a cent. The same question handed to an agent — one that reads files, calls tools, and loops until done — can cost dollars. Teams are discovering this the hard way: a coding agent left running racks up a bill that a human at a keyboard never would. The scary part isn't the average; it's that you can't predict it in advance, and the cost of the same task can swing wildly.

This page explains why agents burn tokens (the mechanism is not what most people guess), shows the numbers that surprise even experienced builders, and gives you the four levers that actually cut the bill — the same levers whether you're on Claude Code, Cursor, Codex, or a home-grown loop over any model.

What you'll learn
  • Explain the context snowball — why agent cost grows roughly QUADRATICALLY with steps, not linearly
  • Cite the real multipliers: agentic tasks ~1000x a chat's tokens, and the SAME task varying up to 30x
  • Know when a second agent is worth it — and the benchmark showing it usually isn't
  • Pull the four cost levers that work: budget caps, prompt caching, model-tier routing, context pruning
  • Diagnose a runaway agent bill and put a hard ceiling on it

The context snowball: why cost grows quadratically​

Here's the trap. A chat is one turn — one input, one output, done. An agent is a loop: it reads a task, takes an action, reads the result, takes the next action, and so on until the job is finished. The catch is that on every step, the model re-reads the entire accumulated conversation so far — the original prompt, every prior action, and every tool result — before deciding what to do next.

So the input grows on every step, and you pay for the whole snowball again each time it rolls forward:

  • Step 1 processes the prompt.
  • Step 2 re-reads the prompt + step 1's action + result.
  • Step 3 re-reads all of that + step 2's action + result.
  • …and so on.

Add up the input across a run and the total scales roughly with the square of the number of steps, not linearly. The Stanford Digital Economy Lab found agentic tasks to be "uniquely expensive, consuming 1000x more tokens than code reasoning and code chat" — and crucially, it's the input tokens that dominate, not the output. The agent isn't writing more; it's re-reading more.

What you'll learn
  • The cost driver is re-reading, not thinking. Each loop step re-processes the full transcript, so a 20-step run pays for early context ~20 times over.
  • This is why 'just let the agent figure it out' is expensive: every extra step it takes multiplies against everything before it.
  • Output-heavy tasks (write me an essay) are cheap by comparison; input-heavy loops (explore this repo, then fix the bug) are where the money goes.

The numbers that surprise people​

Three figures reset most people's intuition:

  • ~1000x. Agentic tasks can consume roughly a thousand times the tokens of an equivalent chat or code-completion, per the Stanford analysis — driven by the snowball above, not by a bigger model.
  • Up to 30x variance on the same task. The same agent, run on the same task, can cost up to 30x more one time than another — because the path it takes (how many tools it calls, how far it wanders) is non-deterministic. You genuinely cannot know the bill until it's done. This is why "result-based pricing" for agents is so hard: you only see the cost after everything runs.
  • More agents rarely pay for themselves. 2026 production benchmarks found that a multi-agent setup added only ~2.1% accuracy at 2x the cost versus a well-configured single agent on 64% of tasks. A hierarchical-supervisor pattern pushed a document task from 85% → 95% accuracy — but at roughly $0.15/task vs $0.003 for the single agent (~50x). More agents buys a little accuracy for a lot of money.
Watch out
  • Because the same task varies up to 30x, an average-based budget WILL be blown by the tail. Cap the ceiling, don't budget the mean.
  • Adding agents to 'be safe' usually multiplies cost far faster than it adds accuracy. Reach for a second agent only when the task genuinely decomposes into parallel, independent subtasks.

Your tool surface is part of the bill​

Before the loop even starts, how the agent reaches its tools sets a floor on cost. Connecting a set of MCP servers can inject tens of thousands of tokens of tool definitions into every step of the snowball. A rough comparison many builders hit: a plain CLI command averages ~200 tokens, while the equivalent MCP operation can cost 32k–82k tokens once tool schemas and wrapping are counted. That gap rides along on every loop step.

That doesn't make MCP wrong — it's the right choice for auth, multi-tenancy, and governed access. It means the tool surface is a cost lever you chose at design time. AILmanac has a dedicated deep-dive: The MCP Token Tax covers Tool Search, deferred loading, and code execution as the three fixes.

The four levers that actually cut the bill​

Optimization advice is endless; only four levers move the number materially. In rough order of leverage:

Guided walkthrough1 of 4
  1. Set a per-run or per-user token/dollar cap that HARD-STOPS the agent. Because the same task can cost 30x more on a bad run, a ceiling is the only thing that bounds the tail. Most agent harnesses expose a max-tokens or max-steps limit — use it. This is the single most important control.

Audit a runaway agent (paste your run's token breakdown)

You are a cost engineer. Here is a token-usage breakdown of one agentic run
(input vs output tokens per step, tool calls, model used).

Diagnose where the money went, in priority order:
1. Is input or output driving cost? (Agents are almost always input-heavy.)
2. Which repeated content should be prompt-CACHED (system prompt, tools, rules)?
3. Which steps could run on a CHEAPER model without losing correctness?
4. Where is context snowballing — what can be pruned, compacted, or summarized?
5. What is a safe per-run token CAP that stops the worst tail without hurting the median run?

Give me the estimated % saving per fix and the ONE change to make first.

When an agent is the wrong tool​

The cheapest agentic run is the one you don't make. If a task is a single, well-specified transformation — summarize this, classify that, rewrite this — a plain chat/completion call does it at a fraction of the cost, with no snowball at all. Reach for an agent when the work genuinely requires reading, deciding, acting, and re-checking in a loop against a changing environment (explore a repo, debug across files, drive a browser). If you can write the exact steps yourself, script them — don't pay a model to re-derive them every run.

Pressione Enter ou Espaço para virar o cartão. Use as setas esquerda e direita para navegar entre os cartões.Termo exibido.
1 / 5

Check yourself

0/3
  1. Why does an agentic run cost so much more than a single chat turn for the same question?
  2. A teammate wants to add a second and third agent 'to be safe' on a task a single agent already handles at 85% accuracy. What do the 2026 benchmarks suggest?
  3. Given that the SAME task can cost up to 30x more on one run than another, what's the right way to control spend?

Sources & further reading​