Guide
A single API call and a 200-step agent loop don't just differ in call count. They differ in how fast cost compounds. This page walks through the math, and how to catch it before the invoice does.
The argument, in one table
Each step re-sends everything said so far, so input tokens, and cost with them, grow faster than the number of steps. The runaway row has no ceiling on step count at all.
| Scenario | Steps | Input tokens | Output tokens | Cost per run | Cost per 1,000 runs |
|---|---|---|---|---|---|
| Single callOne request, one response. It's the baseline every other row is measured against. | 1 | 800 | 400 | $0.0056 | $6 |
| Short tool-use agentA handful of tool calls (search, fetch, read a file), each one re-sending everything said so far. | 5 | 13,000 | 1,500 | $0.041 | $41 |
| Task / coding agentA multi-file coding or research task: reading, editing, and re-reading its own prior output. | 20 | 219,000 | 7,000 | $0.508 | $508 |
| Multi-agent fan-outOne task split across several sub-agents running the same tool-use pattern in parallel. | 10 | 50,500 | 3,000 | $0.655 | $655 |
| Runaway loopno ceilingThe horror case CostMon exists to catch. A loop with no per-run step ceiling, still going. | 200 | 18,390,000 | 70,000 | $37.48 | $37,480 |
Every number here comes from the same open formula. Input tokens grow with step count, priced at Claude Sonnet 5's published rate. The runaway row is real. See cited AI-agent bills that ran into six and seven figures before anyone noticed.
Why it happens
A single API call bills once. An agent step bills once per step. Every step re-sends the entire transcript so far as new input tokens. That includes the original task, every prior tool result and every reply. Input cost grows with the square of the step count, not linearly. That's because each of the N steps re-sends roughly N times as much accumulated context as the first one did.
A search result, a file read, or an API response gets pasted back into context as input tokens on the next step. It's usually far larger than anything the model itself generated. A run heavy on tool use can carry an input-to-output ratio many times wider than a plain chat conversation. That matters because most people budget for AI cost by estimating output length alone.
A tool call that times out adds a full extra step. So does a rate limit that triggers a retry. So does a step the agent redoes after a bad result. Each one re-sends the same accumulated context again. A retry rate that looks trivial in isolation compounds with everything above it.
Splitting a task across several sub-agents is often the right call for latency or coverage. But it multiplies total cost by however many agents are running, on top of whatever each individual agent's step count already costs. Five parallel agents at the same per-agent cost is a 5x bill, not a rounding error.
A plain API integration has a natural cap: one request in, one response out. An agent loop has no equivalent default. Nothing stops it at step 20 instead of step 200 unless something is explicitly built to stop it. So a bug, a bad prompt or an edge case the agent can't resolve becomes an open-ended loop. The loop keeps re-sending an ever-larger context until something else intervenes.
How to fix it
Cap how many steps a single run is allowed to take, and how many total tokens it can consume. Once it hits either limit, it stops and reports back instead of continuing indefinitely. A budget that's hit is a signal to look, not a silent failure, and that's far cheaper than a loop that runs unbounded.
Most steps in a multi-step run (summarizing a tool result, checking a simple condition, formatting output) don't need a Frontier-tier model. Reserve the most capable, most expensive tier for the steps that need it, and route the rest to a Fast-tier model. That can cut the per-step rate substantially without changing the run's step count at all.
The system prompt, tool definitions, and task description usually stay identical from step to step even as the rest of the context grows. Caching that stable prefix means the provider charges a small fraction of the normal input rate for re-processing it on every subsequent step. That matters most on the long, many-step runs this page is about.
Runs that don't need an immediate interactive response (a scheduled sweep, a bulk classification job) are often eligible for a provider's batch API. It charges a meaningfully lower per-token rate than the standard synchronous endpoint, for the same total work.
Every control above still assumes someone notices when it's not working. A budget nobody reads is just a number in a config file. A daily, normalized view of AI spend sits next to the rest of the stack. Anomaly alerting on top of it catches a runaway agent within a day or two of the start. Compare that to the end of the billing period, when the only remaining option is damage control.
A CostMon anomaly rule can also watch tokens per request, catching the shape an agent loop's fan-out takes before it shows up in spend. See how the detection math decides, with the real triple-gate logic running in your browser.
Prompt caching and batch processing above are two of five levers modeled in full. See how to cut your LLM bill without downgrading your product for the stacked savings waterfall and the exact prompt-caching break-even.
Want to check whether a runaway loop already happened? The AI Spend Analyzer reads a real Claude or OpenAI usage export and flags the exact day-over-day spike pattern this page describes.
FAQ
A single call bills once, for one prompt and one reply. An agent run is many calls chained together. Unlike a plain conversation, most of those calls re-send the entire accumulated transcript and every prior tool result as new input tokens. That makes input cost grow much faster than the step count itself: doubling the number of steps typically more than doubles the total cost.
The most direct lever is a per-run ceiling: a maximum step count and a maximum total token budget. The run isn't allowed to exceed either one before it has to stop and report back. Three more levers reduce the rate without touching the ceiling. Route easy sub-tasks to a cheaper model tier. Cache the stable parts of the prompt. Batch non-interactive work.
At step k, the input is the base prompt plus k times the per-step growth. That growth is everything re-accumulated so far. The output is a roughly constant amount per step. Sum input and output across every step, and price each side at a model's published per-token rate. Multiply the result by however many agents run in parallel, and you get the cost of one full run. It's the same formula for every row in the table, just with different step counts and growth rates.
The figures on this page are a planning model built from published list prices, not a bill. CostMon connects directly to the cost APIs of Anthropic, OpenAI and other providers. It normalizes real AI spend into the same daily dashboard as your cloud and SaaS costs. That way, a runaway agent appears as a spike in a number you're already watching, not a surprise at the end of the month.
Part of The Cloud & AI Cost Optimization Playbook: CostMon's cornerstone guide to cutting cloud and AI spend.
Model prices and rate limits change between invoices. CostMon tracks your AI spend daily, so a change shows up before the bill does.