What an AI Agent Run Actually Costs

Last reviewed: 9 October 2026. Prices change quarterly — check the date before you trust the numbers.

Method disclosure, up front: the prices in this article are Anthropic's published first-party rates as of 9 October 2026. The token counts are a model, not a measurement of your workload — every assumption is stated and every number is reproducible with a calculator. Swap in your own token counts and the structure still holds. Where a conclusion depends on an assumption, we say so.

Most teams budget agents the way they budget a chat endpoint: tokens in, tokens out, multiply by the price. Then the first real invoice arrives and it is four to ten times the estimate.

The gap is not a pricing surprise. It is three structural properties of agent runs that a single-request estimate cannot see:

1. Every turn resends the whole conversation. Cost grows super-linearly in turn count, not linearly.
2. Caching is not a minor optimisation. On a realistic run it is the difference between $2.56 and $0.84.
3. Failed runs are paid for twice. The unit that matters is cost per completed task, not cost per request.

This article builds the model, runs the arithmetic, and shows where each effect bites.

The run we are costing

A code-review agent. It receives a diff, reads the surrounding files, and reports findings. One run looks like this:

Model: Claude Opus 5.5 — $4.00 per million input tokens, $20.00 per million output tokens. Cache reads are 0.05× the input price ($0.20/MTok); a 5-minute cache write is 1.25× ($5.00/MTok) and a 1-hour write is 2× ($8.00/MTok).

Step 1: the naive estimate, and why it is wrong

The estimate most people make: 42,000 input + 7,200 output, once. That is $0.168 + $0.144 = $0.31 per run.

It is wrong because turn 2 does not start from nothing. It resends everything turn 1 saw, plus what turn 1 produced. Turn 3 resends that, and so on.

Input tokens on turn t = 42,000 + 1,500 × (t − 1).

Summed across 12 turns: 12 × 42,000 + 1,500 × (0 + 1 + … + 11) = 504,000 + 99,000 = 603,000 input tokens.

$2.56, not $0.31. The naive estimate was off by 8×, and nothing unusual happened — the agent simply took twelve turns.

Step 2: what caching actually does

The 42,000-token prefix is identical on every turn. Cached, you pay to write it once and then read it at 5 % of the input price.

A 67 % cut, from one configuration change. No capability traded, no model downgrade. This is why caching is the first lever, before model choice: it is the only one that costs nothing in quality.

Two things that are easy to get wrong here:

Cache reads refresh the TTL. With a 5-minute cache, consecutive turns keep the entry alive. You pay one write, not twelve.

Unless a human is in the loop. If your agent pauses for an approval and the reviewer takes six minutes, the entry expires and the next turn pays the write again. Two writes instead of one costs $0.42. A 1-hour cache write costs 2× base — $0.336 for this prefix — which is cheaper than paying the 5-minute write twice. So the decision rule is not "use the cheaper TTL":

If any pause in your run can exceed the TTL, the longer TTL is the cheaper option. For human-in-the-loop agents, that is almost always.

Step 3: where caching stops helping

Run the same agent for 40 turns instead of 12 — a plausible outcome when a task is harder than expected or the agent is looping.

3.3× the turns, 4.6–6.8× the cost. Two things are happening:

• Cost is quadratic in turn count. Resending history means turn count enters the sum twice.
• Caching's share of the saving decays. At 12 turns the uncached tail is 99,000 tokens; at 40 turns it is 1,170,000 — and the tail is billed at full price. The cached prefix becomes a smaller and smaller fraction of what you pay. At 40 turns, the delta alone ($4.68) is more than the entire 12-turn cached run.

The remedies are structural, not configuration:

• Cap turns. A task budget tells the model its ceiling so it paces itself and finishes, instead of being cut off mid-thought by max_tokens.
• Move the cache breakpoint forward as the conversation grows, so yesterday's tail becomes today's cached prefix.
• Clear what the model no longer needs. Old tool results are usually the largest removable block in a long run.

Step 4: model choice, and the cache trap inside it

Running the identical 12-turn workload on Claude Haiku 4.5 ($1.00 input / $5.00 output, cache reads at the standard 0.1× = $0.10/MTok):

Note the ordering: uncached Haiku ($0.64) is cheaper than cached Opus ($0.84) — but that comparison is a trap, because it prices two different qualities of work as if they were the same. If the cheap model needs two attempts where the expensive one needs one, it is not cheaper. See step 5.

The non-obvious cost of mixing models: caches are scoped per model. A cascade that routes some turns to a cheap model and some to an expensive one maintains two cache namespaces and gets full reuse in neither. Before building a cascade, price the simpler alternative — the capable model at lower reasoning effort — which keeps one cache namespace and often matches a cheaper model's quality at a lower total cost per task.

Step 5: the unit that actually matters

Everything above prices one attempt. Agents fail: a tool errors, output fails validation, the run loops and gets killed. Those attempts are billed in full.

If 15 % of runs need one retry, the cost per completed task is $0.84 × 1.15 = $0.97, not $0.84.

This is why cost per completed task is the only agent cost metric worth putting on a dashboard. It captures retries, failed validations, abandoned runs and the extra turns a weaker model needs — and it is the only metric under which "use the cheaper model" can be tested rather than assumed. A model that is 60 % cheaper per token and fails 40 % more often is not a saving.

To measure it you need two numbers per run: total tokens billed, and whether the run produced an accepted result. Most teams have the first and not the second. The second is the one that changes decisions.

The model, in one table

Per run, for any workload:

prefix_tokens          P
appended_per_turn      A
turns                  N
output_per_turn        O

uncached input  = N·P + A·(N·(N−1)/2)
cached input    = P·write_rate + (N−1)·P·read_rate + A·(N·(N−1)/2)·input_rate
output          = N·O·output_rate
per completed   = total ÷ (1 − failure_rate)

The term that will surprise you is always A·N(N−1)/2. It is the one a single-request estimate omits entirely, and at high turn counts it is the whole bill.

What to do on Monday

1. Turn on prompt caching and verify it. Check that cache-read tokens are non-zero across repeated requests. If they are zero, something in your prefix changes between calls — a timestamp, an unsorted JSON key, a varying tool list — and you are paying full price for a cache you think you have.
2. Pick your TTL from your pause profile, not from the price list. Human-in-the-loop runs want the long TTL.
3. Cap turns, and alert on runs that approach the cap. They are where the quadratic lives.
4. Instrument accepted-vs-attempted. Then recompute everything above per completed task.
5. Only then consider the model. Caching and turn discipline are free; model downgrades are a quality trade, and they need an eval to justify.

For the batch path: asynchronous work runs at 50 % of standard prices across the major providers. If a workload has no latency requirement — nightly reports, backfills, bulk extraction — that is a 50 % cut with no quality trade, and it stacks with caching.

Sources

• Anthropic prompt caching pricing multipliers (5-minute write 1.25×, 1-hour write 2×, cache read 0.1× with 0.05× on Opus 5.5 / Sonnet 5.5): Anthropic prompt caching documentation, retrieved 9 October 2026.
• Model prices (Opus 5.5 $4/$20 per MTok; Haiku 4.5 $1/$5 per MTok): Anthropic published API pricing, 9 October 2026.
• Batch discount and caching savings ranges in production: Reduce LLM API Costs: 6 Techniques, LLM cost optimization guide 2026.

Not tested hands-on: the token counts in the worked example are a stated model, not an instrumented trace of a production run. The prices and multipliers are published figures, linked above.

← All articles