An agent resends the entire conversation on every turn, so history is billed again each time it grows. The cost is quadratic in turns, which is why agent bills surprise people.

Computed from this tool’s default settings — turns in the task and the rest as most people start. Change them below for your own case.
A 20-turn task bills about 445K input tokens — 11.7× the 38K of actual content, because every turn resends the history. Prompt caching is the fix: the prefix is identical every turn, so a high hit rate cuts the dominant term to a tenth.
Why a coding agent bills far more than the tokens you think you sent.
A 20-turn task bills about 445K input tokens — 11.7× the 38K of actual content, because every turn resends the history. Prompt caching is the fix: the prefix is identical every turn, so a high hit rate cuts the dominant term to a tenth.
| Turns | Billed input | Cost | Per turn |
|---|---|---|---|
| 5 | 55K | $0.221 | $0.0442 |
| 10 | 148K | $0.555 | $0.0555 |
| 20 | 445K | $1.560 | $0.0780 |
| 40 | 1,490K | $4.920 | $0.1230 |
| 80 | 5,380K | $17.040 | $0.2130 |
Every input moves the result for a reason. This is what each one does and where to find the value for your own machine.
| Setting | Default | What it changes |
|---|---|---|
| Turns in the task | 20 turns | One turn is one model call — a tool use and its result. |
| System prompt and tools | 8000 tokens | Resent on every single turn unless it is cached. |
| New content per turn | 1500 tokens | Tool output plus the model’s own reply, which both stay in the history. |
| Input price | 3 per 1M | Your own figure in per 1M, starting from 3. Change it to match what you actually run. |
| Output price | 15 per 1M | Your own figure in per 1M, starting from 15. Change it to match what you actually run. |
| Prompt cache hit rate | 0 % | Anywhere from 0 to 100 %. |
The same calculation run at a range of settings, with everything else left at its default. These are computed by the tool itself, not written by hand.
| Turns in the task | Cost per task | Billed input | Content you wrote | Resend multiplier |
|---|---|---|---|---|
| 1 | $0.035 | 8K tok | 10K tok | 0.8× |
| 26 | $2.379 | 696K tok | 47K tok | 14.8× |
| 51 | $7.535 | 2,321K tok | 85K tok | 27.5× |
| 75 | $15.131 | 4,763K tok | 121K tok | 39.5× |
| 100 | $25.800 | 8,225K tok | 158K tok | 52.1× |
A 1-turn task bills about 8K input tokens — 0.8× the 10K of actual content, because every turn resends the history. Prompt caching is the fix: the prefix is identical every turn, so a high hit rate cuts the dominant term to a tenth.
No lookup tables and no invented constants. Here is the arithmetic, so you can check it against your own numbers.
An agent resends the whole conversation on every turn, so the history is billed again each time it grows. Total input is the sum of a growing prefix, which is quadratic in the number of turns — doubling the turns roughly quadruples the input cost, not doubles it.
This is why prompt caching matters more for agents than for anything else. The prefix is identical turn to turn, so a high hit rate turns the quadratic term into a tenth of itself.
These are well-founded engineering estimates, not benchmark results. Your quantisation, runtime and context length all move the real number, and usable memory is an assumption rather than a specification. See the full methodology for every assumption behind these figures.
The three situations that bring people to this calculation.
See what a task really costs.
Find the resend multiplier behind the number.
Quantify what a cache hit rate saves.
Four steps, no account, nothing leaves your browser.
Start at the top of the panel. Every figure recalculates as you change it — there is no submit button, because watching the number move is the point.
5 further settings: system prompt and tools, new content per turn, input price, output price, prompt cache hit rate. Defaults are the common case, so change only what differs for you.
The large figure answers the question. The table underneath shows how the answer changes across nearby settings, which is usually where the decision actually gets made.
The arithmetic is written out above. If a number looks wrong for your hardware, the assumptions are the first place to look — usable memory and quantisation are the two that vary most.
The questions people ask about this, answered without hedging.
Because the conversation is resent every turn. Twenty turns of 1,500 new tokens is 30,000 tokens of content but roughly 300,000 tokens of billed input, since turn twenty pays for everything turns one to nineteen produced.
Because every turn resends the whole history. Twenty turns of 1,500 new tokens is 30,000 tokens of content but roughly 300,000 tokens of billed input — turn twenty pays for everything the first nineteen produced.
No, it roughly quadruples it. The billed input is the sum of a growing prefix, which grows with the square of the turn count.
Prompt caching first — the prefix is identical each turn, so a high hit rate cuts the dominant term to a fraction. Then keep tool output terse, and start fresh tasks rather than continuing one long session.
Sometimes, but a weaker model often takes more turns to finish, and turns are the term that grows quadratically. Cost per task can rise even as cost per token falls.
All 50 run on the same arithmetic, so answers across them agree.
Different ways of asking the same question, all resolved above.
Sizing is only half the problem. Model Radar takes your hardware and shows which models actually run on it, ranked by what they are good at — the same arithmetic as this page, applied to every model worth running.