Guides / agent loop cost
Why the cap you set doesn't cap what an agent spends
In a tool-use loop every request carries its own output cap, so the limit bounds a single step rather than the whole turn. Ten steps under one cap cost ten times it. Culpa, a local-first LLM cost, margin, and forecast ledger, prices every call and groups them by run, so a turn reports its own total rather than its steps.
Why this happens
Almost everyone treats the output cap as the cost ceiling on a request, and for a single call that holds. An agent isn't a single call. It's a loop: the model asks for a tool, your code runs it, the result goes back, and the model decides again. Anthropic says this plainly, that in a tool-use loop each request in the turn has its own cap so it doesn't bound the whole turn's spend. The ceiling anyone set applies per step and nothing applies to the loop. Two things then compound it. Reasoning interleaves with tool use automatically, so the model can think between every tool call, and that reasoning bills as output at each step. And the conversation grows: each step re-sends everything before it, so input tokens climb with step number while output stays flat. The result is a run whose cost is superlinear in its step count, governed by a cap that was never measuring it.
What this usually looks like
- One agent run costs far more than your per-call cap suggests it can.
- Cost per run varies wildly and nobody knows how many steps a run takes.
- Your ceiling is set per request and there's no ceiling on a run.
- Input tokens per call climb through a run while output stays level.
- A runaway agent was caught by a bill rather than by a limit.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Treating the per-request output cap as a spend ceiling. | It bounds one step, and a loop takes as many steps as the model decides it needs. | Cap the number of steps as well, which is the only limit that bounds a run. |
| Measuring cost per call in an agent. | The unit a user experiences is the run, and a run is an unknown number of calls. | Group calls by run and report cost per run, including its step count. |
| Forgetting that reasoning happens between tool calls. | Interleaved thinking bills as output at every step, so it multiplies with loop length. | Watch the reasoning share per step, and lower effort if it's not earning its place. |
| Ignoring that each step re-sends the history. | Input tokens grow with step number, so late steps cost more than early ones. | Cache the stable prefix and trim what the model no longer needs. |
Run this check tonight
- Find your longest agent run last week and count its steps.
- Multiply your per-request output cap by that step count.
- Check whether anything at all limits the number of steps a run may take.
- Plot input tokens against step number for one run and look at the slope.
A cap of 4,096, and a turn that spends ten times it
Illustrative example
Anthropic states that in a tool-use loop each request has its own output cap, so the cap doesn't bound the whole turn's spend. Take an output cap of 4,096 tokens and an agent that takes ten steps to finish a task, priced on the price book's real Claude Opus 5 output rate of $25.00 per million. Output only, to isolate the effect the cap is supposed to control. The cap and the step count are modelled, the rate and the behaviour are published.
The cap did its job perfectly at every step and bounded nothing that mattered. Input isn't even in these numbers, and input is the part that grows, because every step re-sends the whole conversation before it. The only limit that bounds a run is a limit on steps.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $1.0240 against $0.1024 | modelled cost of a ten-step agent turn against the single-step cap that was supposed to bound it | calculated | Anthropic's thinking-steering-and-cost page, read 2026-08-05, states that in a tool-use loop each request in the turn has its own max_tokens so it doesn't bound the whole turn's spend. At the price book's real Claude Opus 5 output rate of $25.00 per million, one 4,096-token step costs $0.1024 and ten such steps cost $1.0240, exactly ten times. Output only, input excluded. The cap and step count are modelled, the rate and the behaviour are published. |
What a generic answer can’t know
How many steps a run takes is decided by the model at runtime, and it's a property of the task rather than of your configuration. Nothing outside your own system observes it, which is why cost per run is so rarely reported and cost per call so commonly is. Culpa prices every call and carries whatever identifiers you attach, including the run, so a turn's calls aggregate into one figure with its step count beside it. That makes the distribution visible rather than the average: the runs that took forty steps instead of four, which task types produce them, and whether the expensive tail is worth serving. Set it against what those customers pay and a run reports margin, which is the only version of the question that tells you where to put a limit.
Questions founders ask next
Does max_tokens limit what an agent spends?
No. Anthropic states that in a tool-use loop each request in the turn has its own max_tokens, so it doesn't bound the whole turn's spend. It caps a single step, and a loop takes as many steps as the model decides. Only a limit on step count bounds a run.
Why does one agent run cost so much more than another?
Step count, mostly. Cost scales with how many times the loop goes round, and that's decided at runtime by the task rather than by your settings. Input also grows through a run because each step re-sends the conversation before it, so late steps cost more than early ones.
How do I actually cap agent spend?
Limit the number of steps a run may take, and record cost per run so you know what a normal one looks like. A per-request output cap is still worth setting, and it's controlling a different thing from the one most people assume.
Does reasoning make agent loops more expensive?
It can, because thinking interleaves with tool use automatically and bills as output at every step. In a long loop that multiplies. Whether it's worth it depends on whether the reasoning between tool calls improves the decisions, which is measurable on your own runs.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
Keep reading
Sources: Anthropic, steering thinking and its cost, Anthropic pricing. Last reviewed 2026-08-05, rates effective 2026-07-02. Plain text version.