What does one agent run actually cost?
Most calculators price a single API call. An agent makes dozens of them, and every step re-sends everything that came before it. Input tokens grow with the square of the step count. This models that.
31 models · No signup · Nothing leaves your browser
A 12-step agent. 2,000-token system prompt, 500-token task, 400 output and 1,200 tool-result tokens per step, zero retries. The calculator below defaults to a 10% retry rate, which reports 6.9×, because retries re-send context too.
Model your workload
Set the shape of one agent run. Everything recalculates as you drag, and the URL updates so you can share the exact configuration.
Workload
Scale
Compare with a person optional
Cost of one run
…Agent versus a person
Where the money goes
Same workload, every model
| Model | Per run | Per month | vs. best |
|---|
Cost accumulation by step
| Step | Context sent | Step cost | Running total |
|---|
i equals system + input + (i−1) × (output + tool result), which makes total input tokens grow as O(N²) rather than O(N). Capping steps or trimming tool output beats switching models more often than teams expect.Why agent costs surprise people
Language models are stateless. They remember nothing between calls, so an agent has to re-send its entire history on every step. Step 1 sends a little. Step 2 re-sends step 1 plus whatever is new. Step 10 pays for steps 1 through 9 all over again.
Total input tokens across N steps come out as:
That second term is quadratic. Double the steps and you roughly quadruple the input cost. It is the most consistent reason real invoices beat estimates.
Which half of the formula matters flips early, and this is where most cost-cutting goes wrong. The system prompt and the task sit in the linear term. Only the output and tool results carry the quadratic one. For the workload below the two are equal at about four steps; by step 12 the quadratic term is 78% of billed input, and by step 50 it is 94%. So shortening the system prompt attacks the part that has almost stopped growing. Cache it instead, and spend the effort on step count and tool-result size.
A worked example
A 12-step agent with a 2,000-token system prompt, 500-token task, 400 output tokens and 1,200 tool-result tokens per step has a raw conversation length of 21,700 tokens, and bills 135,600 input tokens. That is a 6.2× multiplier which shows up on the invoice and in nobody's estimate.
The 6.2× figure is the context effect on its own, at a 0% retry rate. The calculator defaults to a more realistic 10% retry rate, which is why it reports 6.9×. Retries re-send context too. Set retries to zero to isolate the pure loop effect.
The three levers, in order
- Prompt cachingMost of the bill is context re-sent verbatim, and cache reads cost roughly 90% less. In the example above, a 90% hit rate takes the run from $0.351 to $0.096 on Claude Sonnet 5.5. Same model, same agent. The system prompt is the one segment sent byte-identical on every call, which makes it the easiest thing to cache and the wrong thing to trim.
- Step countCutting steps beats switching to a cheaper model in most configurations, because step count is superlinear while price is linear. Going from 20 steps to 10 saves more than moving from a frontier model to a small one.
- Tool-result sizeUnderrated, because every tool result is re-sent by every step that follows it. Truncating a 5,000-token search result to 1,000 compounds across the whole run.
Assumptions and limits
Retries are modelled as a flat multiplier on total cost. Real retries occur at a specific context depth, so failures late in a run are under-counted. Cache hit rate is a single figure rather than per-prefix. Providers use different tokenizers, so cross-vendor token counts are approximate. The same is true inside Anthropic's own lineup: Claude 4.7 and later, which is every Claude model here except Haiku 4.5, use a newer tokenizer that turns the same text into about 30% more tokens than Haiku 4.5 does. Entering one token count and comparing those models therefore understates what Sonnet 5.5 bills for the same work. Batch pricing and cache writes are options, off by default. Writes use the shortest retention, 5 minutes at Anthropic and 30 at OpenAI, and long-context price tiers are still not modelled. Treat the output as a planning estimate, not a billing forecast.
Each model carries one rate, so tiered pricing is flattened, and the direction of the error differs by provider. DeepSeek bills peak and off-peak, with off-peak half the peak rate; the figures here are peak, so a run scheduled outside 01:00 to 04:00 and 06:00 to 10:00 UTC on a weekday costs about half what is shown (Chinese public holidays count as off-peak all day). OpenAI, xAI, Google and Anthropic's Claude Haiku 5.5 instead raise rates once a single request gets large, and the figures here are the base tier, so a long agent is undercharged rather than overcharged. Haiku 5.5 changes gear first, at 100K prompt tokens, where input, output and cache rates all rise 5×. Grok and Gemini change gear at 200K tokens, Grok by doubling every rate. OpenAI's threshold is higher at 272K, where the whole request is rebilled at 2× input and 1.5× output, taking GPT-6 Astra from $10 / $50 to $20 / $75. On the default workload the largest single request is about 81K tokens at 50 steps, so this starts to bite at roughly 62 steps on Haiku 5.5, 125 on Grok and Gemini and 170 on OpenAI. A 100-step Haiku 5.5 run costs about 3.5 times the figure shown.
Questions
Why does an AI agent cost more than the token math suggests?
N × (system + user) + (output + tool result) × N × (N−1) / 2. The second term is quadratic, so a 12-step agent with a 2,000-token system prompt and 1,200-token tool results bills about 135,600 input tokens against a raw conversation length of 21,700.