Agent loop cost estimator

What it does

An agent calls a model, runs the tool the model asked for, and calls the model again with everything so far: the instructions, the tool definitions, the task, and every earlier call and tool result. So each step sends more than the one before it, and a run of thirty steps can cost many times what thirty separate calls would suggest. This is often the most surprising line on an AI bill.

Describe one run:

• Steps — how many times the model is called.
• System prompt and tool definitions — the fixed beginning of every call.
• The task — what the agent was asked to do, also sent on every call.
• Tool result added per step — the file, page or command output that comes back after each step, on average.
• Output per step — what the model writes each time (the tool call or the answer), including any reasoning tokens.
• Prompt caching — none, the system prompt and tools only, or the whole conversation so far — and the share of steps that find the cache.

The estimator prices every step, draws the run's cumulative cost against the same run without caching, and lists every step in a table: its input size, what the cache did, its price band and its cost.

Everything runs in your browser. Nothing you enter is sent anywhere.

How it computes

Step k sends the prefix, the task and every earlier exchange:

input(k) = system and tools + task + (k − 1) × (output per step + tool result per step)

Each step is then priced on its own by the function Salyro prices usage with (calculateCost), from the model's own price list. That matters for models with price bands: a step whose input crosses a band threshold — "input over 272,000 tokens", say — is priced entirely at the higher band's rates, input and output alike, and the steps before it are not. The run's total is the sum of the steps' own costs, each worked out and rounded by that function for that step alone.

Caching. With the system prompt and tools cached, a hit reads them at the cached-input rate and a miss writes them to the cache. With the whole conversation cached, the cache point moves to the end of each step's input: a hit reads everything the previous step sent and writes only what is new, and a miss writes the whole input. The first step is always a miss, because the cache starts empty. The hit rate is a share of the steps that can find the cache — every step after the first whose cached part (the system prompt and tools, or the previous step's whole input) is at least the provider's minimum cacheable length — rounded to whole steps and spread evenly over them, so each step is priced as a definite hit or miss. This is not quite the prompt caching calculator's hit rate, which is a share of all calls (the first always missing): here it is a share of the steps that could hit at all. A conversation that only reaches the minimum after a few steps has fewer steps that can hit; the result shows how many hits were priced, of how many steps that could.

A cache write is billed at the price list's cache-write rate wherever writes are known to be billed — the price list has such a rate, or the provider's own page says so. Only where nobody has read how a provider bills writes can you choose to bill them as ordinary input. A prompt shorter than the provider's minimum cacheable length is not cached at all.

Warnings. The estimator flags the first step priced in a higher band, and the first step that no longer fits the model's context window, where that window is known.

What it does not know

• Your agent's real shape. Tool results vary from step to step, some agents summarise or trim their history, and some run several tool calls in one step. The estimator uses averages and a history that only grows.
• Time between steps. A cache entry lives for a limited time after it is last read — the provider's lifetime, named under the result where its page could be read. A step that takes longer than that (a slow tool, a human in the loop) lets the entry expire, and the next step misses whatever the hit rate says.
• Context windows the provider's page did not tell us. Where a model's window could not be read from its provider's documentation, it is unknown, and no step is checked against it.
• No fallback to the input rate. A model whose price list has no cached-input or cache-write rate is not priced for the steps that need one, and the total says it is partial. It is never priced at the ordinary input rate instead.
• Thinking carried in context. Some providers keep earlier reasoning in the conversation and bill it as input on later calls. Include it in the output per step if yours does.
• It does not simulate the calls an agent would make, and it does not run an agent.

FAQ

Why does the cost grow faster than the number of steps?

Every step sends the whole conversation so far, so the input grows by one output and one tool result per step. The total input over a run grows with the square of the number of steps. Caching the growing conversation is what keeps that in check.

Why is my Anthropic run "partial"?

Anthropic's page says a cache write costs more than ordinary input, and Salyro's price list has no cache-write rate for its models yet. A step that writes to the cache is therefore not priced here rather than priced at the input rate, and the total counts only the steps that are.

Why does the line stop?

The line shows the run so far. It stops at the first step that is not priced, because a running total past that point would leave out a cost.

Sources

Prices come from Salyro's catalogue, with the revision and each provider's pricing page named under the result. Context windows, minimum cacheable lengths and cache-write billing name the provider page they were read from, and the date. Anthropic's extended thinking and thinking cost pages (extended thinking, thinking steering and cost) describe how earlier thinking blocks stay in context and are billed as input.