Prompt caching for agent loops: cut input costs

Prompt caching lowers agent costs because an agent re-sends the same long prefix (tools, instructions, history) on every turn, and cached reads are billed at a small fraction of the normal input price. As of October 2026, in Anthropic's API a cache read costs 0.05x the base input price on Claude Opus 5.5 and Sonnet 5.5 (0.1x on most other models), against 1.25x for a 5-minute write. The catch: a change early in the prompt silently throws away the saving from that point on. This is what to check, in order.

Why agent loops are expensive on input

An agent turn is not one request. The model calls a tool, reads the result, and calls another tool. Each step is a new API request that carries everything before it: tool definitions, system prompt, every earlier message and every tool result.

So input tokens grow with each turn, and you pay for the whole history again each time. In a long loop the repeated input often dominates the bill, even though output tokens cost more each.

Every pass re-sends the whole history; caching changes how it is billed.

How much can caching save?

Here is a worked example. Assume a 50,000-token prefix (tools, instructions, retrieved documents) and 20 turns that each add little. Prices are expressed as multiples of the base input price, using the Sonnet 5.5 multipliers documented as of October 2026: 1.25x for a 5-minute cache write and 0.05x for a read. It assumes every turn starts within the 5-minute lifetime and ignores the write cost of each turn's small new content.

• Without caching: 20 turns x 50,000 tokens = 1,000,000 token-equivalents.
• With caching: one write (62,500) plus 19 reads (19 x 2,500 = 47,500) = 110,000 token-equivalents.

That is roughly a 90% drop on the cached part of the input. It is not a drop of the whole bill: output tokens, new uncached text and tool results are billed as usual.

No caching1000 k

With 5-minute cache110 k

Illustrative numbers, not a benchmark. Computed from the documented Sonnet 5.5 multipliers: 1.25x write, 0.05x read.

How do you turn it on?

You have two options, both described in the prompt caching documentation:

1. Automatic caching. Add one top-level cache_control field. The breakpoint moves to the last cacheable block as the conversation grows, which suits agent loops as long as each turn adds fewer than 20 blocks, the lookback window.
2. Explicit breakpoints. Place up to 4 cache_control markers yourself, for example after the tool definitions and after the system prompt.

Two limits matter. A prompt shorter than the model's minimum is simply not cached, with no error. As of October 2026 that minimum is 512 tokens for Opus 5.5, Sonnet 5.5 and Haiku 5.5, and higher for some older models (for example 4,096 for Haiku 4.5). And the default lifetime is 5 minutes, refreshed on every use. If your agent pauses longer than that between turns, for example while waiting on a human, consider the 1-hour option ("ttl": "1h"), which costs 2x the base price to write.

What silently breaks the cache?

Cache hits need a 100% identical prefix. The prompt is cached in the order tools, then system, then messages, and a change at one level invalidates that level and everything after it. According to the same docs, these changes cost you the cache:

• Editing a tool definition (name, description or parameters) invalidates tools, system and messages.
• Changing tool_choice invalidates the messages cache.
• Adding or removing an image anywhere invalidates the messages cache.
• Changing thinking parameters or output_config.effort always invalidates the messages cache, and on some models the tools and system caches too.

The most common self-inflicted wound is putting something that changes every request, such as a timestamp or a request ID, near the top of the system prompt. Put stable content first and variable content last.

Does clearing old tool results help?

Long loops eventually hit context limits as well as cost. Context editing (a beta feature as of October 2026) clears the oldest tool results on the server once the prompt passes a trigger. The documented defaults are a 100,000-input-token trigger and the 3 most recent tool uses kept.

It trades against caching. Clearing tool results invalidates the cached prefix from the point where content is removed. The docs advise setting clear_at_least, so each clearing removes enough tokens to be worth the cache write that follows. In practice: clear rarely and in large chunks, not a little on every turn.

How do you verify the saving?

Read the usage fields on every response. The docs define cache_creation_input_tokens, cache_read_input_tokens and input_tokens (uncached tokens after the last breakpoint). If both cache fields are 0, the prompt was not cached, usually because it was too short.

A healthy loop shows a large cache_read_input_tokens on every turn after the first. If it drops to zero mid-run, the prefix changed, the cache expired during a long pause, or the breakpoint moved past the lookback window.

What we would check first

When we look at an agent that costs too much, we start with the usage fields, not the prompt. Is the read count high after turn one? If not, we diff the prefix between two requests. Then we check the pause length against the cache lifetime, and only then look at model choice or context clearing. We would not promise a percentage before seeing real traffic. If you want a second pair of eyes on an agent's cost, see our services.

General information, not financial or technical advice. Prices, limits and beta features change: confirm them in the vendor's current documentation before you build.