Free tool

Agent run cost estimator

An agent resends its history on every step, so the context it carries grows with the square of the step count. This prices one run, one month, and the share that is context you are paying for again.

Assumes one model for the whole loop. Mixed loops are cheaper, which is the point of the last card below.

One run is one complete task: a ticket handled, a document processed, a request answered.

Every trip to the model counts, including the ones that only decide which tool to use next.

System prompt, tool schemas and the task itself. Sent on every step.

The model's own reply plus whatever the tool returned. This is the number that compounds.

What the model writes at each step, before the final answer.

15%

Extra steps from calls that fail and are tried again. Retries that eventually succeed leave no trace except on the invoice.

Estimated cost, each month

$15,070

That is $0.3014 per run, across 50,000 runs.

45.1% of this bill is context resent from earlier steps

Model calls per run, with retries
9.2
Input tokens read per run
82,064
Of that, context resent from earlier steps
45,264
Resent context, as a share of the bill
45.1%

An estimate. It models a fixed-length loop with a constant amount added per step, which is the common shape but not every shape. Rates last checked 2026-08-20.

Why do agent costs grow faster than agent usage?

Because every step reads everything that came before it. A ten step run does not send the prompt ten times, it sends the prompt ten times plus nine steps of accumulated replies and tool results, and it pays the input rate on all of it. Output grows in a straight line with the number of steps. The context carried forward grows with the square of them. That is why an agent that was cheap in a demo of three steps becomes the largest line on the bill once it runs twelve steps against real tickets, and why the growth arrives without anybody shipping a change.

Double the steps in a loop and the context it carries forward roughly quadruples.

Nothing about the workload changed. The loop just got longer.

Where it goes

Four levers, in the order they usually pay.

None of these reduces what the agent does. Each is a cheaper route to the same completed run.

Give the loop a terminal state
A ceiling on steps and a definition of done. Loops without one do not fail loudly, they run long and bill quietly. This is the largest single lever on almost every agent.
Cache the stable head
The system prompt and tool schemas are identical on every step of every run, and prompt caching bills them at roughly a tenth of the input rate. This is the direct answer to resent context. Price it on the caching calculator.
Trim what each tool returns
Most tools return a full payload where the model reads three fields. Every extra token is carried forward into every later step of the run, so trimming a tool result once saves it many times over.
Split the loop across models
Routing, tool selection and extraction rarely need a frontier model, while the final synthesis often does. Running the cheap steps on a small model is the difference between the top and the bottom of the price list.
FAQ

About agent costs

Why does an agent cost so much more than the number of steps suggests?

Because the history travels with it. On step one the model reads the system prompt and the task. On step two it reads all of that again plus its own first reply and the first tool result. By step ten it is reading nine steps of accumulated context before it does anything.

Output grows in a straight line with the step count. The context carried forward grows with the square of it. Double the steps and that carried context roughly quadruples, which is why the bill climbs faster than the step count does.

What counts as a step?

One call to the model. A single agent run that reads a ticket, searches twice, calls an API, drafts a reply and checks its own work is six steps, and every one of them is a separately billed request carrying everything that came before it.

Why does the retry rate matter so much?

Because a retry that eventually succeeds never looks like a failure. It does not appear in an error dashboard, nobody files a ticket, and the only trace it leaves is on the invoice. A loop with a 30% retry rate is a third more expensive than the one anybody designed.

Retries also land late in the run, where the accumulated context is longest, so each one costs more than an average step.

What actually brings this number down?

Four things, in the order they usually pay. Cap the loop so it has a terminal state. Turn on prompt caching for the stable head of the conversation, which is the direct answer to resent context. Trim what each tool result adds to the history, since most tools return far more than the model reads. Then move the steps that do not need a frontier model onto a smaller one, which is often most of them.

How exact is this?

It models one shape of loop: a fixed number of steps, a constant amount added to the history per step, and retries as extra steps. Real agents branch, summarize, and drop context, so treat the figure as an order of magnitude and the trend line as the real finding. Rates were last checked 2026-08-20.

This is one agent. You have more than one.

Book 30 minutes. We connect a read-only view of every provider you pay and show the cost of each agent and workflow separately, with the loops that grew fastest at the top.

5 minute setup. Read-only. No engineering time needed.