Skip to content

Agent Loop Visualiser: Where the Tokens Actually Go

Step count on a slider, input tokens per step as bars, and the exact cost of a run — showing why an agent's bill grows with the square of its steps.

Input tokens per step — every bar re-sends everything below it
Cost of one 8-step run
$0.15

Step 8 alone sends 8,410 input tokens — 3.7× step 1. Doubling the step count roughly quadruples the input bill, because the history is re-sent every time.

Base context re-sent every step
2,250 tokens
Added to the history per step
880 tokens
Input tokens, step 1
2,250
Input tokens, step 8
8,410
Total input tokens for the run
42,640
Total output tokens for the run
1,440
Input cost
$0.13
Output cost
$0.02
Cost per 1,000 runs
$149.52
What this assumes: the full conversation is re-sent on every step, which is how a stateless chat completions API works and therefore how almost every agent loop works. No prompt caching — with caching the base context and the settled prefix bill at the cached rate instead, which flattens the curve substantially but does not remove it, since each new observation invalidates nothing before it but is itself uncached on first send. Action and observation sizes are held constant across steps; in practice observations vary wildly and one large file read dominates everything after it. Closed-form total: n·B + (a+o)·n(n−1)/2 input tokens, where B is the base context.

Why the last step costs so much more than the first

An agent loop looks linear when you draw it — plan, act, observe, repeat — and it is linear in wall-clock steps. It is not linear in tokens. Every step re-sends the system prompt, the tool schemas, the original task, and every action and observation that came before it. The nth step therefore carries roughly n times the history of the first, and the total across the run has an n² term in it.

The practical consequence is that agent cost is dominated by the tail. In an eight-step run the last three steps are usually more than half the bill. Anyone who has capped an agent by step count has felt this: going from 10 steps to 20 does not double the cost, it roughly quadruples it, and the budget you set from a five-step test run is wrong by a factor of several.

Two of the fields do far more damage than the others, and the bars will show you which. Tool schemas are pure fixed cost — they are re-sent on every step whether the model uses them or not, so a bloated schema is rent you pay n times per run. Observation size is the growth term: it enters the history and is then re-sent for the remainder of the run, so a tool that returns 4,000 tokens of raw JSON at step two is charged again at every step after it. Truncating tool output at the source is usually the single largest saving available in an agent, and it is visible here as the slope of the bars rather than their height.

What this does not model is quality. Fewer steps and smaller observations are cheaper and sometimes worse. The number here is the budget, not the verdict.

Agent Loop Visualiser: Where the Tokens Actually Go · Multigrid