What AI Agents Really Cost: The Multi-Step Token Multiplier

Teams estimate agent costs by testing one step, pricing that call, and multiplying by an expected step count. That estimate is reliably wrong, because it treats every step as costing the same as the first one. In a real agent loop, each step resends the entire trajectory so far — every prior tool call, every tool result, every intermediate thought — which means step 5 can cost several times what step 1 cost, on the exact same model.

Anatomy of an Agent Step

A single agent "step" is one model call, and it typically carries:

• System prompt + tool schemas. Instructions plus the JSON schema for every tool the agent can call — resent on every step, since the model has no memory between calls.
• The original task description. What the user or upstream system asked for, carried through the whole run.
• The full trajectory so far. Every previous step's reasoning, tool call, and tool result — this is the part that grows every single step.
• This step's output. A short reasoning fragment and a tool call, or a final answer once the task is done.

Tool results are usually the biggest driver of growth. A search result, a database query response, or a file read can easily run several hundred tokens — and unlike a chatbot's conversation history (see our chatbot cost estimation guide for that comparison), agent trajectories often grow faster per turn because tool output is rarely as compact as a human reply.

Worked Example: A 6-Step Agent Task

Assumptions:

• System prompt + tool schemas: 600 tokens, resent every step
• Initial task description: 60 tokens
• Reasoning + tool call output per intermediate step: 80 tokens
• Average tool result appended to context: 350 tokens
• 5 tool-using steps, then 1 final synthesis step producing a 250-token answer

Per-step input tokens, growing as the trajectory accumulates:

• Step 1: 660 input tokens
• Step 2: 1,090 input tokens
• Step 3: 1,520 input tokens
• Step 4: 1,950 input tokens
• Step 5: 2,380 input tokens
• Step 6: 2,810 input tokens

Summed across the full run:

• Total input tokens: 10,410
• Total output tokens: 650

The Multiplier: Real Cost vs the Naive Estimate

The naive estimate prices step 1 in isolation (660 input tokens, 80 output tokens) and multiplies by 6 steps: 3,960 input tokens, 480 output tokens. The actual run used 10,410 input tokens — a 2.63x multiplier over the naive number, purely from context growth across steps. On output tokens the naive estimate is off too, since it doesn't account for the larger final synthesis step.

Priced out on two commonly used agent models, for the real (non-naive) token totals:

• GPT-4o mini: $0.0020 per run
• Claude Sonnet 5: $0.0273 per run

At 3,000 agent runs a month, that's $5.85 on GPT-4o mini versus $81.96 on Claude Sonnet 5 — and using the naive per-step estimate instead of the real trajectory total would have underbudgeted either model by roughly the same 2.6x factor.

Why Tool Result Size Matters More Than Step Count

It's tempting to budget an agent by step count alone — "this task takes about 6 steps, so multiply by 6." Step count matters, but the size of what gets appended at each step matters more, because it's the thing that compounds. Doubling 350 tokens of tool result per step to 700 roughly doubles the growth rate of every subsequent step's input — the effect isn't linear in the number of steps you add, it's closer to linear in the size of what each step contributes to a trajectory that every later step has to carry forward in full.

In practice this means two agents with the same step count can have very different costs depending entirely on what their tools return. A weather-lookup tool that returns a 40-token JSON object barely moves the needle across ten steps. A document-search tool that returns full page contents on every call can dominate the entire run's cost by step three or four — and it's usually the least visible line item in a pre-launch estimate, because nobody budgets tool output size the way they budget system prompt length.

Models Commonly Used in Agent Loops

Many production agents don't use one model for every step — cheap, fast models handle routine tool selection and formatting steps, while a stronger model is reserved for planning or the final synthesis. See how to pick the cheapest model that's still good enough for the cascading pattern this relies on.

Controlling the Multiplier

• Cap max steps hard. An agent with no step limit on an ambiguous or adversarial task can loop far longer than any test run suggested. A hard cap bounds your worst case, even if it occasionally cuts off a legitimate long task.
• Truncate or summarize tool results before they enter context. Most tool outputs (search results, API responses, file contents) carry far more detail than the model needs. Extracting the relevant fields before appending to context, instead of dumping the raw response, is often the single biggest lever on trajectory growth.
• Summarize old steps instead of keeping them verbatim. Once a tool result has been acted on, a one-line summary ("checked inventory: in stock") usually carries the same planning value as the full original result, at a fraction of the tokens.
• Cache the stable prefix. The system prompt and tool schemas don't change step to step — that's exactly the kind of static content prompt caching is built for. See LLM pricing explained for how caching mechanics work.
• Route by step type, not by task. A tool-selection step rarely needs a flagship model; a final synthesis or ambiguous planning step might. Pricing every step at the same model tier is usually over-spending on the easy steps.

Multi-Agent Systems Multiply This Again

An orchestrator pattern — one model breaking a task into subtasks and dispatching them to specialized sub-agents — adds another layer on top of everything above. The orchestrator pays its own growing-trajectory cost for planning and coordination, and each sub-agent runs its own independent step loop with its own growing trajectory. A three-subagent research task isn't "triple the cost of one agent" in the simple sense; it's the orchestrator's own multi-step cost plus the sum of however many steps each sub-agent independently takes, which is often harder to predict in advance than a single agent's step count because sub-agent difficulty varies by subtask. If you're designing a multi-agent system, budget each agent's trajectory separately using the same method as above, then sum them — don't assume a flat multiplier per sub-agent, since some subtasks genuinely need far more steps than others.

Common Mistakes

1. 1. Estimating from a single test run. One successful trajectory in testing tells you almost nothing about the distribution of step counts real tasks will take — budget from a range, not a point estimate.
2. 2. No hard step cap. Without one, a stuck or looping agent can run indefinitely, and cost grows roughly with the square of step count as trajectory length compounds.
3. 3. Dumping raw tool output into context. Unprocessed API responses and search results are usually 3-10x larger than the information the model actually needs from them.
4. 4. Using one model for every step. Planning and synthesis steps often justify a stronger model; routine tool-selection steps rarely do. Uniform model choice leaves savings on the table.
5. 5. Not tracking cost per completed task in production. Test-time token counts drift once real users send messier, more ambiguous requests that take more steps to resolve — production telemetry, not a pre-launch estimate, should be the source of truth after week one.

FAQ

Is the multiplier always around 2-3x?

No — it depends entirely on how many steps a task takes and how large each tool result is. Short, low-tool-use tasks might see a multiplier close to 1x; long research or multi-tool tasks with large intermediate results can see 5x or more. Compute it for your own trajectory shape rather than assuming a fixed number.

Does prompt caching eliminate the multiplier?

It reduces the cost of the static portion (system prompt, tool schemas) but does nothing for the part that actually drives the multiplier — the growing trajectory of tool results and prior reasoning, which is different on every step and therefore not cacheable.

Should every agent have a step cap?

Yes. Even a generous cap (20-30 steps, for example) protects against the worst case of a stuck loop, which is a real and common failure mode, not a hypothetical one. Pair it with logging so you can see how close real tasks come to the cap and tune it over time.

How is this different from a plain multi-turn chatbot?

The underlying mechanic — growing context resent every turn — is the same. Agents tend to grow faster because tool results are usually larger and less compressible than a typical chat reply, and because agent tasks often run more turns before completion than a typical support conversation.

Model this against your own workflow in detail with the Agent Workflow Calculator.