Direct answer
Agent loops get expensive when yesterday's context becomes tomorrow's input
A multi-turn agent does not necessarily pay for the same isolated prompt repeatedly. Retained conversation history, repository context, and tool results can make later model calls larger. This calculator exposes that arithmetic, then applies an expected retry multiplier and separate input/output API rates.
Price a multi-turn coding-agent loop
Enter one representative loop and current usage-based model rates. The worksheet runs only in this browser.
Total API-equivalent cost
$0.58
Input plus output at the rates entered; not a subscription invoice or allowance.
Expected attempts
6.9
6 planned turns + 0.9 expected retry attempts
Cumulative input
151,800
Growing turn inputs multiplied by expected retry overhead.
Cumulative output
8,280
Output per turn multiplied by expected attempts.
Input cost
$0.455
78.6% of this API-equivalent estimate
Output cost
$0.124
21.4% of this API-equivalent estimate
Input context before retries, turn by turn
Each bar is the modeled input for one planned turn. Retry overhead is applied to the cumulative totals above, not duplicated as invented integer bars.
- Turn 112,000 tokens
- Turn 216,000 tokens
- Turn 320,000 tokens
- Turn 424,000 tokens
- Turn 528,000 tokens
- Turn 632,000 tokens
Worked example
Six turns with growing context and 15% retries
The starting worksheet uses 12,000 initial input tokens, 2,500 tokens of retained growth, 1,500 tokens of tool results, and 1,200 output tokens per turn. Planned input rises from 12,000 to 32,000 tokens across six turns. The unadjusted input sum is 132,000 tokens; multiplying input and output by 1.15 produces 151,800 expected input tokens and 8,280 expected output tokens. At $3/M input and $15/M output, the API-equivalent estimate is $0.5796: $0.4554 input plus $0.1242 output. These are illustrative assumptions, not observed averages or current prices for a named model.
Four parts of the loop compound differently
Retained context
Input growth is paid again on every later turn when history remains in the prompt.
Tool results
Only tool output that re-enters model context is counted as tokens; executing the tool itself is not model usage.
Retries
The multiplier repeats the modeled input and output mix as expected overhead.
Rate asymmetry
Output can contribute disproportionate cost when its per-million rate exceeds input.
Reduction levers to test one at a time
01
Trim repeated context
Pass the smallest relevant code and instructions into each turn; avoid resending unrelated repository material.
02
Summarize tool output
Return compact structured results instead of raw logs when the detail is not needed by the next model call.
03
Compact deliberately
Measure the token effect of agent compaction or summarization instead of assuming all history stays verbatim.
04
Reduce retry causes
Separate transient failures, invalid tool arguments, and evaluation retries so one average rate does not hide the dominant cause.
Where this model can undercount or overcount
- It can undercount when
- The agent adds hidden system context, tool schemas, retrieved files, retry prompts, evaluator calls, subagents, or longer-than-entered outputs. Parallel branches and model fallbacks also need separate scenarios if they are not represented by the retry rate.
- It can overcount when
- The agent compacts or discards old history, truncates tool results, uses prompt caching at a discounted rate, routes some turns to cheaper models, or stops before the planned turn count. This simple model assumes linear retained growth until the loop ends.
- Tool execution boundary
- A database query, shell command, or MCP operation is not itself model tokens. Count only the request/argument tokens emitted by the model and result text that is sent back into a later model context. External tool fees require a separate cost line.
- Retry boundary
- The shared calculator applies one retry fraction uniformly to cumulative input and output. If retries happen mostly on late, context-heavy turns—or repeat input without full output—the uniform multiplier can differ from the real request sequence.
Cost is not quality, productivity, or plan entitlement
Usage describes volume
More or fewer tokens do not establish answer quality, developer productivity, task difficulty, model efficiency, or whether the loop achieved its goal. Compare outcomes separately with a task-appropriate evaluation.
API equivalent describes one price model
The result is usage-based input/output math. It is not a subscription invoice, remaining allowance, credit balance, fair-use threshold, tax calculation, negotiated rate, or promise that a plan includes the modeled requests.
Calibrate the worksheet with a real loop
01
Observe
Capture turn count, token buckets, retry causes, and the point where context was compacted.
02
Model
Enter a representative linear scenario and save the assumptions beside the result.
03
Reconcile
Compare the estimate with provider usage and billing, then adjust the input that explains the gap.
Methodology and limitations
Turn sequence. The calculator floors the non-negative turn input to a whole count. Planned turn n receives initial input plus n − 1 times the sum of retained input growth and tool-result tokens. The displayed bars show that pre-retry sequence; the function sums it before applying retry overhead.
Expected retries. Retry rate is a fraction capped at 1. Expected attempts equal turns × (1 + retry rate). Both summed input and per-turn output are multiplied by that factor and rounded to token counts. Fractional attempts are statistical expectation, not literal partial API calls.
Pricing. Cumulative input and output use the custom per-million rates entered in the browser. The result excludes cache-specific rates, external tool charges, subscription terms, credits, discounts, taxes, and provider routing. Current provider billing remains authoritative.
Privacy and limitations. Inputs and calculations remain in the browser and are not submitted by this worksheet. The model is linear, while real agents may compact history, truncate tool output, branch into subagents, switch models, or retry particular turns with a different token mix. Use measured traces to calibrate assumptions; do not use token cost as a proxy for quality or productivity.
Sources
- LiteLLM model pricing dataset
Public model pricing reference used for API-equivalent estimates; provider billing remains authoritative.
- Data collection and privacy methodology
Explains what the CLI aggregates, what it does not collect, and the limits of the public cohort.