Agent Run Cost Estimator

Prices a multi-step agent run including the context it resends on every step, at your mean step count and at your p90.

Fixed prefixSystem prompt plus every tool schema. Sent on every step.

tokens

Steps per run (mean)One step = one model call plus its tool result.

steps

Steps per run (p90)The slow tenth. Your own number from your traces — this tool will not invent a spread.

steps

Model output per stepInclude reasoning tokens if the model emits them.

tokens

Tool result per stepWhat comes back from the tool and goes into the context.

tokens

Runs per month

runs / mo

Input rate$ per 1M tokens

per 1M

Cached input rate$ per 1M tokens. Set it equal to the input rate to model no prefix caching at all.

per 1M

Output rate$ per 1M tokens

per 1M

Monthly agent spend, at the mean run

$1,142

If every run went to p90 (20 steps) it would be $5,812 — 5.09× as much.

Input tokens per run: 43,800
…of which is context replay: 23,800 (54.3%)
Output tokens per run: 2,000
Cost per run (mean): $0.11
Cost per run (p90): $0.58
p90 ÷ mean: 5.09×
Cost of one more step, at the mean depth: $0.02
Monthly at the mean: $1,142
Monthly if every run hit p90: $5,812

What this assumes: the full history is resent on every step, with no summarisation, no trimming and no dropped tool results — the moment you compact the context, the quadratic term stops applying and this over-estimates; the fixed prefix is a cache hit from step 2 onward, which requires the prefix to be genuinely byte-identical every time; cache writes are not billed separately here, so if your provider charges a write premium add it to the first step; tool execution itself (the API you call, the code you run) is not an LLM cost and is not counted; failed runs that get retried are counted only if you include them in the runs figure.

The reason agent costs surprise teams that have already built chat features is that they are not linear in steps. Each step resends everything the run has accumulated, so the input bill over n steps grows with n², not n. Doubling the average step count from 8 to 16 does not double the bill — it roughly triples the input half of it. That is the single most important shape on this page, and it is visible in the "cost of one more step" row: the marginal step is always dearer than the average one, and by the twentieth step it is several times dearer.

It is also why the p90 matters more than the mean. Agent step counts are not normally distributed; they have a long right tail made of runs that got stuck in a loop, retried a failing tool, or wandered. Because cost is quadratic in depth, the slow tenth of your runs can account for more than half the spend. Pricing only the mean run is how a feature passes its cost review and then triples its bill in production.

Two levers this makes visible. Trimming tool results is worth more than trimming the system prompt, because an observation is paid for on every subsequent step while the prefix is cached. And a hard step limit is a cost control, not just a safety one — capping runs at the p90 converts an unbounded tail into a known ceiling. What this does not model: sub-agents with their own contexts, parallel tool calls within one step, or the cost of whatever the tools themselves are doing.

Agent Run Cost Estimator

The reasoning behind this

Related tools