Price a single agent call and it looks trivial: 8,000 tokens of context, 400 tokens back, a fraction of a cent. Then the agent takes twelve steps to finish the task, and each step re-sends everything that came before it. That is the number people miss, and it is the number this calculator is built around.
The context is re-sent every step, and it grows
An LLM has no memory between calls. To let an agent "continue," your framework resends the entire conversation each step — the system prompt, the tool definitions, every earlier tool result, every earlier reply — and appends the newest tool output on top. So the input the model reads on step 10 is not 8,000 tokens, it is 8,000 plus everything the first nine steps accumulated.
Model it and the shape is quadratic. With an initial context of I, and each step adding g tokens (a tool result plus the model's own reply that also joins the history), the total input processed across n steps is n·I + g·n(n−1)/2. Take the calculator's defaults — 12 steps, 8,000 initial, 1,900 added per step — and that is 96,000 + 1,900 × 66 = 221,400 input tokens for one task, against the 8,000 a single call suggested. The "accumulation tax" stat is exactly this ratio: how many times more you pay than a flat n × I would predict.
Why a budget model that loops beats a frontier model that loops
Because the bill is dominated by re-read input, the input price and your caching discipline matter more than raw model quality per token. A frontier model at $5/$30 running a 12-step task on the defaults costs dollars per task; a budget model at $0.10/$0.10 running the same loop costs cents. The table prices every model on your exact step shape so you can see the spread, which is routinely 50× or more — far wider than the quality gap for the mechanical sub-steps most agents spend their steps on (reading files, running searches, calling tools).
The practical move is rarely "use the cheapest model for everything." It is to let a cheap model drive the loop and reserve an expensive one for the one or two steps that genuinely need it. The model switch savings calculator prices that split.
Caching is the lever that actually moves this
The re-sent prefix is stable — same system prompt, same tools, same early history in the same order — which is the exact condition prompt caching rewards. Set the cached-input share to reflect how much of each step's input is that unchanging prefix; on a long-running agent it is often 70% or more. Because caching discounts the repeated portion by up to 90% on some models, it attacks the quadratic term directly, which is why it outperforms almost any other optimisation here. The prompt caching savings calculator derives the hit rate you need for it to pay off, and why output tokens cost more explains the price asymmetry the table is built on.
What this deliberately leaves out
Two things widen a real bill above this estimate. The first is reasoning tokens: if your agent uses a reasoning model, each step's output line understates what you are billed, because the hidden thinking is charged at the output rate — price that separately in the reasoning token cost calculator. The second is retries and dead ends: a step that fails and is re-attempted still cost you its full accumulated context. This calculator prices a clean run of n steps; multiply by your real success rate to get the honest figure.
Prices used by this calculator were last verified on 31 August 2026 from the vendors' own pricing pages. See the full price index for every figure and its source, the change log for what has moved recently, and the methodology for how the index is maintained and where its limits are.