Does trimming an AI agent's context save money?

Usually not, and in the worked example below the arithmetic runs the other way for any run shorter than about twenty-five turns. Anthropic's invalidation table says an image added or removed anywhere in a prompt invalidates the message cache, so an agent that drops an old screenshot re-writes every remaining message at 1.25 times base input price.

The mechanism is that a prompt cache is matched on an exact prefix. Editing the history does not shrink the prompt so much as move the point where the match stops.

Prices, token counts, cache minimums and invalidation rules below were checked by Unity Horizon on 14 September 2026 against Anthropic's prompt caching documentation, its pricing page and its vision documentation.

What invalidates a prompt cache?

Anthropic publishes the cache as three ordered levels, tools then system then messages. A change at one level invalidates that level and every level below it.

What changes	tools	system	messages
A tool definition	gone	gone	gone
Web search or citations toggled	kept	gone	gone
The speed setting	kept	gone	gone
tool_choice	kept	kept	gone
An image added or removed anywhere	kept	kept	gone

The last row is the one that catches agents. Remove a screenshot from turn three and the message cache stops matching from turn three onward, so the model re-reads a conversation you have already paid to have read once.

The cache does not care which image moved. It cares that one did.

What does trimming an agent's history cost?

Take a computer use agent on Claude Opus 5. Declaring computer_toolset_20260801 with its default members adds about 4,520 input tokens on that model. Add a 1,000 token system prompt. Each turn appends one 1920x1080 screenshot, which costs 2,691 visual tokens on the high-resolution tier that covers Claude 4.7 and later, plus roughly 300 tokens of tool call and tool result text. After ten turns the warm prefix is 35,520 tokens.

Now drop the five oldest screenshots, 13,455 tokens, to keep the window manageable.

Line, on the next request	Keep the history	Drop five screenshots
Tools and system, 5,520 tokens	cache read at 0.1x, 552	cache read at 0.1x, 552
Older messages	30,000 at 0.1x, 3,000	16,545 at 1.25x, 20,681
This turn's screenshot and text	3,000 at 1.25x, 3,750	3,000 at 1.25x, 3,750
Billed, in base input tokens	7,302	24,983

The trim costs 17,681 base input tokens on the spot, $0.088 at the Opus 5 list price of $5 per million. It saves 1,346 tokens on every later request, two thirds of a cent. Fourteen more turns and it is even. A run that finishes before that paid for the privilege of a shorter prompt.

What is the most expensive thing an agent can change mid-run?

A tool definition, by a distance. That change invalidates all three levels, so the entire 35,520 token prefix is re-written at 1.25x rather than read at 0.1x. Twelve and a half times the price of the same tokens, $0.222 against $0.018, on one request.

Editing the tool list mid-run is the pattern this catches, and MCP has made it easy to do by accident. A router that selects tools by relevance, a registry that adds a server mid-session, a flag that hides an admin tool from junior operators, a retry path that drops a failing tool, an eval run that shuffles definitions for coverage: each one rewrites the whole prefix at full write price. The demo always has a tool list that never changes. Loading tools through Anthropic's tool search is the exception, because a discovered tool is appended to the conversation as a tool_reference block and the prefix is untouched.

An agent that flips tool_choice from auto to a forced tool on its last step gets off lighter. That one keeps tools and system warm and re-writes only the messages.

Four explicit cache breakpoints are allowed per request, and automatic caching consumes one of them. Put the volatile content after all of them, never before.

Why does a five minute cache expire in four?

Because the clock starts earlier than you think. Anthropic's documentation states that the lifetime "is measured from the start of the request that writes or reads the cache entry, not from the end of its response", and adds that if a response takes four minutes to stream, the follow-up has about one minute to begin.

Generation counts against the window. So does whatever your tool does next. We built OFFSET, which files declarations directly to the ΑΑΔΕ portal, and a browser step against a portal is not a sub-second operation.

The one hour window costs 2x on the write rather than 1.25x, and Anthropic's pricing page says outright that it pays off after two cache reads against one for the short window. An agent whose turns are separated by slow tool calls is the case the longer window exists for. Reading a cached entry refreshes it at no extra charge, so a loop that keeps hitting never pays the write again.

The short window rewards a fast loop. The long window rewards a loop that waits.

Does a cheaper model still cache?

It caches, but from a much higher floor. Claude Opus 5 caches prompts from 512 tokens. Claude Haiku 4.5 needs 4,096, eight times as much, and a prompt under the minimum is silently not cached with no error returned.

Model	Minimum cacheable prompt	Base input	Cache read
Claude Opus 5	512 tokens	$5 / MTok	$0.50 / MTok
Claude Sonnet 5	1,024 tokens	$2 / MTok	$0.20 / MTok
Claude Haiku 4.5	4,096 tokens	$1 / MTok	$0.10 / MTok

A small assistant moved down the price list to save money can land under the floor and lose the discount that was doing most of the work. There is a second trap in the same table: Anthropic notes that Claude 4.7 and later models use a newer tokenizer producing approximately 30% more tokens for the same text, so a per-million comparison across model generations is not comparing the same text.

Do OpenAI and Google document the same rules?

Partly. All three cache on a prefix. Only Anthropic publishes what breaks it level by level.

	Anthropic	OpenAI	Google
How it turns on	cache_control on the request or a block	on by default for supported models	implicit on Gemini 2.5 and later
Cached read price	0.1x base input on Opus 5	0.1x on GPT-5.6 and later	not stated on the page
Minimum	512 tokens on Opus 5	1,024 tokens on GPT-5.6 and later	4,096 tokens on Gemini 3.1 Pro Preview
Window	5 minutes, or 1 hour at 2x write	30 minutes from last use on GPT-5.6 and later	not stated on the page
Invalidation rules	a published table	"the entire rendered prefix" must match	not stated on the page

OpenAI's page names model, tools, output format, reasoning effort and context management settings as things that change the prefix, without a per-level table. Google's caching page gives minimums and says cost savings are passed on, without saying by how much or what misses. On Gemini the discount is real and the rules are unpublished, so the usage field is the only instrument you have.

What changes on Monday?

Append-only agents win here and rewriting agents pay. An agent that only adds to the end of its context holds a warm prefix across a whole run for a tenth of base input. An agent that summarises, prunes, re-orders or hot-swaps tools re-writes at 1.25x each time it touches the past, and the bill arrives as cache creation tokens rather than as anything labelled a mistake.

Two changes follow from the table. Freeze the tools and the system prompt for the life of a run, so every volatile thing sits after the last breakpoint rather than before it. When the context genuinely has to shrink, open a new conversation from a summary instead of editing the old one, because a cold cache you planned is cheaper than a warm one you broke.

Then watch cache_read_input_tokens against cache_creation_input_tokens on every response. That ratio is the only place this shows up before the invoice.

This is arithmetic over published list prices rather than a measurement of our own runs. We have not published a cache hit rate, and the figure that would settle the question, how often a production loop holds its prefix across a slow tool call, is one we have not counted. If you have counted yours, we would rather quote your number than model around it.

Pull one agent run from last week and add up its two cache fields. Scoping that loop is the kind of work we do, and the related failure, an agent doing the same thing twice, reads out of the same log.

What share of your input tokens came back as cache reads, and what moved in the prefix to spoil the rest?