Five rows grow from one tile to five, each repeating earlier tiles and adding one orange tile.

Where agent tokens go: each turn pays for every turn before it

Priced out, a 30-turn agent loop with 2,000-token tool results sends 1,240,500 input tokens for 9,000 out. A stable cached prefix cuts that bill 80%; a broken one adds a quarter.

Andrei Gaspar

· 9 min read

An agent loop resends its whole history on every turn, so the input it sends grows with roughly the square of the turn count. Tool results inflate every turn after them, retries repeat turns, and sub-agents multiply the lot. LLM cost optimization for agents starts with that shape, not with the price per token.

The price per token is the number on the pricing page, and the number teams compare. It is one of two factors. The other is how many times each token gets sent, and in a loop the answer is once per remaining turn. A tool result returned at turn 3 of a 30-turn run rides along in all 27 requests that follow.

This piece prices one 30-turn run, then ranks five levers by what each one costs you: caching, trimming tool results, caps on turns and retries, smaller models for sub-tasks, and fewer agents. It ends where cutting tokens starts cutting the work.

Every turn pays for every turn before it

The mechanism is the loop from the agent loop piece: send the context, run the tool the model asked for, append the result, send again. The model keeps nothing between requests. Whatever it needs at turn 20, the harness sends at turn 20, turns 1 through 19 included.

So the cost of a turn is the size of the context at that turn, and the context only grows. Call the fixed prefix p tokens and the per-turn growth g. Turn t sends p + (t - 1) * g. A run of n turns sends n * p + g * n * (n - 1) / 2, and the second term is the square. Nobody wrote a quadratic into the harness. It came with an append inside a while.

Most of what each turn appends is tool output. The model's own share is small: some reasoning and a tool call. Manus, in Context Engineering for AI Agents: Lessons from Building Manus, reports an average input-to-output ratio of around 100:1 in its agent. Output tokens cost more apiece (five times input on the model priced in the next section), but at that ratio input decides the bill.

Retries add turns at whatever size the context has reached. A harness that retries a failed run from scratch pays for the whole triangle again.

Sponsored: Gitdailies — Install today. Move faster daily.

A 30-turn run, priced

Suppose an agent run of 30 turns. The system prompt, tool definitions, and task come to 8,000 tokens. Each turn, the model writes 300 tokens of reasoning and a tool call, and the tool returns 2,000 tokens. Every turn adds 2,300 tokens to the context. Turn 1 sends 8,000 tokens. Turn 30 sends 74,700.

The prices are Claude Sonnet 4.6's, from Anthropic's pricing page as read on October 14, 2026. Per million tokens: $3 for input, $15 for output, $3.75 for a 5-minute cache write, and $0.30 for a cache hit. Sonnet 4.6 is here because its cache prices use the standard multipliers. Some newer models price a hit lower, which comes up in the next section.

This script, run on Python 3.12, computes the cumulative totals with and without caching, plus the variants the rest of the piece uses:

# Token bill for an agent loop that resends its whole history every turn.
# Claude Sonnet 4.6 prices, USD per million tokens, read 2026-10-14.
BASE_INPUT, CACHE_WRITE, CACHE_READ, OUTPUT = 3.00, 3.75, 0.30, 15.00
 
PREFIX = 8_000         # system prompt, tool definitions, task
OUTPUT_PER_TURN = 300  # the model's reasoning and tool call
TOOL_RESULT = 2_000    # what each tool call appends
 
 
def run_cost(turns, tool_result=TOOL_RESULT, cache="off"):
    """cache: "off", "stable" (prefix reused), or "broken" (prefix changes every turn)."""
    growth = OUTPUT_PER_TURN + tool_result
    sent = read = written = 0
    for turn in range(1, turns + 1):
        context = PREFIX + (turn - 1) * growth
        sent += context
        if cache == "stable":
            reused = context - growth if turn > 1 else 0
            read += reused
            written += context - reused
        elif cache == "broken":
            written += context
    uncached = sent - read - written
    dollars = (uncached * BASE_INPUT + read * CACHE_READ + written * CACHE_WRITE
               + turns * OUTPUT_PER_TURN * OUTPUT) / 1e6
    return sent, read, written, dollars
 
 
runs = [
    ("30 turns, no cache", dict(turns=30)),
    ("30 turns, stable cache", dict(turns=30, cache="stable")),
    ("30 turns, broken cache", dict(turns=30, cache="broken")),
    ("30 turns, tool results capped at 500", dict(turns=30, tool_result=500)),
    ("60 turns, no cache", dict(turns=60)),
    ("120 turns, no cache", dict(turns=120)),
]
for label, kwargs in runs:
    sent, read, written, dollars = run_cost(**kwargs)
    print(f"{label:<38}sent {sent:>10,}  read {read:>9,}  written {written:>9,}  ${dollars:6.2f}")
 
sent_30 = run_cost(30)[0]
last_ten = sent_30 - run_cost(20)[0]
print(f"turns 21-30 send {last_ten:,} tokens, {last_ten / sent_30:.0%} of the run")
print(f"four 30-turn workers send {4 * sent_30:,} tokens, ${4 * run_cost(30)[3]:.2f}")
30 turns, no cache                    sent  1,240,500  read         0  written         0  $  3.86
30 turns, stable cache                sent  1,240,500  read 1,165,800  written    74,700  $  0.76
30 turns, broken cache                sent  1,240,500  read         0  written 1,240,500  $  4.79
30 turns, tool results capped at 500  sent    588,000  read         0  written         0  $  1.90
60 turns, no cache                    sent  4,551,000  read         0  written         0  $ 13.92
120 turns, no cache                   sent 17,382,000  read         0  written         0  $ 52.69
turns 21-30 send 643,500 tokens, 52% of the run
four 30-turn workers send 4,962,000 tokens, $15.43

Read the first row as the baseline. The run sends 1,240,500 input tokens and produces 9,000 output tokens, a ratio of about 138 to 1, the same order as the Manus figure. Input is $3.72 of the $3.86. Output, at five times the price per token, is $0.14.

The last ten turns send 643,500 tokens, 52% of the run's input. A third of the turns sends more than half the input. Double the run to 60 turns and it sends 4,551,000 tokens for $13.92: 3.7 times the tokens for twice the turns.

Caching pays only while the prefix holds still

Anthropic's prompt caching docs describe the mechanism in their own order: a cache prefix covers tools, then system, then messages. A later request whose prefix matches reads those tokens at 0.1 times the base input price. Writing them costs 1.25 times base for the 5-minute cache and 2 times for the 1-hour one. The default lifetime is 5 minutes, refreshed at no cost each time the entry is used, and counted from the start of the request. The cache key is a hash of the prompt up to the breakpoint, so only an identical prefix hits.

Put that on the 30-turn run. Assume a breakpoint on the last block of every request, and every turn starting within 5 minutes of the one before. Turn 1 writes its 8,000 tokens. Each later turn reads what the previous request sent and writes only its 2,300 new tokens. Across the run, that is 1,165,800 tokens read and 74,700 written, and the bill falls from $3.86 to $0.76, about 80% less.

The shape changes as well as the size. The triangle is still there, billed at a tenth. After turn 1, the writes are a flat 2,300 tokens a turn. And output, which caching does not touch, grows from 3.5% of the bill to 18% of it.

The third row is the same run with a broken prefix. Suppose the system prompt opens with a timestamp precise to the second, the mistake Manus names as common. Every request now differs from the system prompt onward. With the breakpoint on the last block, nothing ever hits, and every request writes its whole context at 1.25 times base. The run costs $4.79, about a quarter more than not caching at all. The cache did not fail. It billed.

The docs list what breaks a prefix, and an agent harness is placed to do several of them mid-run. Changing a tool definition invalidates the entire cache. Changing tool_choice invalidates the message blocks. Changing the thinking configuration invalidates them too, and on some models the tool and system caches as well. So does adding or removing an image. Manus adds the ones that come from your own code. Keep the context append-only. Serialize deterministically, because JSON key order may not be stable. Mask the tools the agent may not use at a given step instead of removing them; Manus does it by constraining decoding, never by editing the tool list. A harness that loads tools lazily by editing the tools array rewrites the cache each time it does. Anthropic's tool search avoids this: discovered tools are appended to the conversation, so the prefix holds.

Then there is the clock. The lifetime counts from the start of the request, so a slow tool (a full test suite, a cold build) that pushes the next request past 5 minutes returns to an expired entry. The next turn pays the write price on everything. The 1-hour cache costs twice the base price to write. Whether that pays depends on when the long call comes: a miss rewrites the context as it stands at that turn.

Some newer models price a hit lower. The docs put hits on Claude Opus 5.5 and Claude Sonnet 5.5 at 0.05 times base, half the standard multiplier, and hits on Claude Fable 5.1 and Claude Mythos 5.1 at 0.025. On those models a stable prefix is worth more, and a broken one still pays 1.25 times base.

LLM cost optimization, ranked by what each lever costs

Every lever below cuts tokens. They differ in where the bill lands, and that sets the order. The table carries the figures from the 30-turn run where the script computed them, and the sources' figures where it did not:

LeverWhat it savesWhat it costs you
Stable cached prefix$3.86 → $0.76 per runPrefix discipline in the harness; a 1.25× write premium that bills you when the prefix breaks
Tool results capped at 500 tokens$3.86 → $1.90 per runWhatever the cap removed, unless the agent can fetch it back
Caps on turns and retriesTurns 21–30 are 52% of inputRuns that stop before they finish
Smaller model for sub-tasksClaude Haiku 4.5 input at $1 per million, a third of Sonnet 4.6'sMisses on hard cases; a round trip per delegation
Fewer agentsAnthropic reports about 15× more tokens than chat for multi-agent systems, 4× for a single agentParallelism, and fresh windows that can cost less than one long loop

Read the right-hand column top to bottom. The first row costs the model nothing it can see. Each row after it lands closer to the work.

Trimming tool results. Capping each tool result at 500 tokens cuts the per-turn growth from 2,300 to 800 and the run to 588,000 tokens, $1.90. The price is information. An agent cannot know what a cap removed unless the result says so. That is how the search tool in the illustrative postmortem walkthrough got a flag deleted: the reference sat at result 53 of a page of 50. Manus describes compression it keeps restorable: a web page's content can leave the context as long as its URL stays. Truncate with a count of what was cut and a handle to get it back. What to evict, and when, is its own budget.

Caps on turns and retries. Turn 30 sends 74,700 tokens, more than nine times what turn 1 sent. A retry at turn 30 costs the same again. A harness that retries a failed run twice from scratch pays for it three times. A turn cap removes the expensive end of the triangle. It costs every run that needed turn 31. It is only safe when hitting it ends the run with a status a person sees. A cap that stops quietly turns a cost problem into a correctness one.

Smaller models for sub-tasks. Dimitri Mazmanov's write-up of shunt, a Claude Code plugin built on Spotify's Portal, is the cleanest field account of this lever. Two PreToolUse hooks block whole-file reads over a line threshold (350 by default) and point Claude at a skill that sends the file to a worker model, Gemini 2.5 Flash in his examples. Claude gets a summary instead of the file. Across four scenarios on a Java monorepo, he reports mean bulk-read savings of around 90% of Claude's tokens. He also reports the bill. Round trips typically take 10–30 seconds. The worker missed a subtle thread-safety bug in his testing. The routing excludes debugging, architectural decisions, and safety-critical code. Below the line threshold, delegation overhead exceeds the savings.

One more cost of switching models hides in the pricing page. Claude 4.7 and later models use a tokenizer that produces about 30% more tokens for the same text. Compare models on cost per task, never on price per token.

Fewer agents. In its account of how it built its multi-agent research system, Anthropic says agents typically use about 4 times more tokens than chat interactions. Multi-agent systems use about 15 times more. The same post says multi-agent systems need tasks valuable enough to pay for the extra performance. A sub-agent that redoes a sibling's reading is waste, and removing it is the saving.

The triangle also cuts the other way. Suppose a job takes 120 turns in one loop. The script puts it at 17,382,000 tokens and $52.69, with no long-context surcharge: Sonnet 4.6 bills its 1M-token window at standard rates. Split it into four independent 30-turn workers with fresh windows, and they send 4,962,000 tokens for $15.43. That excludes the lead agent's own turns and the merge. Anthropic's post names the property: "Subagents facilitate compression by operating in parallel with their own context windows." The saving holds only while the pieces are independent. Workers that need each other's decisions fail at the seams, which is a taxonomy of its own.

Where cost optimization stops paying

In the BrowseComp evaluation, Anthropic found that token usage by itself explained 80% of the variance in performance. In that evaluation the tokens were the work. Cut them past the waste and you cut the answer.

The 30-turn run shows where the waste ends. Caching takes the bill to $0.76, and $0.14 of that is output no input lever touches. What remains is the triangle at a tenth of the price. The other levers shrink it by removing what the agent reads, the turns it takes, or the model that does the reading. Each of those can change what the agent does.

So the stopping rule is about measurement. Stop when the next lever's cost lands on what the agent sees and you have no eval that would show it getting worse. A cost change without an eval run is a quality change nobody measured. A budget is different. A turn cap and a per-run token limit are worth having at any price. The runaway case is a loop with nothing to stop it, and AI agent cost at that end of the curve is an incident, not a line item.

Monday

Take one long run and pull the usage block from every request in it. The docs give total input as cache_read_input_tokens + cache_creation_input_tokens + input_tokens; chart the three per turn. If cache_creation_input_tokens tracks the whole context turn after turn, something in your prefix changes every request. Diff the serialized prefixes of two consecutive requests and find it.

Then sort that run's tool results by size and cap the largest. Report a count of what was cut and give the agent a way to fetch the rest. Run your eval suite before and after.

Last, read the turn counts of last month's successful runs and set a turn cap and a per-run token budget above the longest. Make hitting either one a failed run with a status, not a quiet stop.

The pricing page shows the price per token; the invoice shows how many times you sent each one.

This blog exists thanks to the support of our sponsors:

GitdailiesQA.techAppSignalSuperlinked

Comments

Loading comments…

Keep reading