A large agent prompt is often a recurring invoice disguised as context. The system instructions, tool schemas, repository notes, and policy text go back to the model on every request, even when 95 percent of that material has not changed. If your workflow makes ten calls against the same context, you can pay to prefill the same prefix ten times.

Prompt caching is the boring fix with unusually good numbers. Anthropic's current documentation lists Claude Sonnet 5 base input at $2 per million tokens and cache hits at $0.20 per million tokens through August 31, 2026. That is a 90 percent reduction for the reused input, not a 90 percent reduction on the entire request. Output tokens still cost the same, and cache writes are not free. The useful question is therefore not “does this provider support caching?” It is “does my request pattern create enough hits to pay back the writes and the work of keeping the prefix stable?”

Prompt cache billing comparison for recurring agent context

The break-even math

Start with the part vendors tend to make sound simpler than it is. Let S be the stable prefix size, W the cache-write price, H the cache-hit price, and B the uncached input price. The first request normally writes S tokens. Later requests are cheaper only if they actually reuse that prefix before it expires or is evicted.

For Anthropic's Sonnet 5 introductory prices, a million-token prefix costs $2 when sent as ordinary input, $2.50 when written to the five-minute cache, and $0.20 when read from cache. The second request therefore costs $0.20 instead of $2 for the stable portion. After the initial write, one hit saves $1.80. The write premium over the ordinary first request is $0.50, so the write pays for itself on the first successful reuse. That is a clean result, but only for the cached portion and only if the prefix is long enough and unchanged.

The five-minute detail matters. Anthropic says the standard cache lasts 5 minutes and is refreshed at no additional cost each time the cached content is used. A coding agent that takes a break for ten minutes may pay another write. A busy support bot may keep a prefix warm all day. The same feature has different economics in those two workloads.

OpenAI's accounting is different on GPT-5.6 and later model families. Its documentation says cache writes are billed at 1.25x the uncached input rate, while cached reads are reported in cached_tokens. Older model families have different write behavior. Do not copy Anthropic's 90 percent headline into an OpenAI cost spreadsheet. Log the provider's actual usage fields and calculate your own blended rate.

A simple monthly estimate is enough for a first decision:

monthly input cost = write_tokens × write_rate + read_tokens × read_rate + uncached_tokens × base_rate

Suppose an agent sends a 100,000-token stable prefix 200 times in a warm window. With Anthropic's Sonnet 5 figures, one write costs $0.25, and 199 reads cost $3.98. Total stable-prefix spend is about $4.23. Sending that same prefix uncached 200 times would cost $40. Caching does not make the agent cheap if it produces huge outputs or loops forever, but it makes repeated context stop dominating the input bill.

A cache-safe agent workflow

First, separate the request into a static prefix and a changing suffix. Put tool definitions, system instructions, stable project conventions, and reference material in the prefix. Put the timestamp, user question, current file diff, tool results, and request ID after the cache breakpoint. The exact ordering is not cosmetic. Anthropic describes its hierarchy as tools, then system, then messages. Changing a tool definition invalidates the cache below it.

Second, begin with the provider's easiest mode. Anthropic's automatic caching is a one-line top-level cache_control change and moves the breakpoint forward as a multi-turn conversation grows. Use explicit breakpoints when different sections have different lifetimes or when you need to pin a large static system block while the conversation changes. Anthropic allows up to four breakpoints, but more markers do not create more savings by themselves.

For OpenAI, treat the prefix as an exact byte-level contract. Keep the same model, tool schema, system text, and serialization order. Use explicit cache breakpoints on GPT-5.6 and later when the stable boundary is clear. Log cached_tokens and cache_write_tokens beside request latency, model name, and a hash of the intended static prefix. A cache hit without an accounting record is just a nice-looking assumption.

Third, warm the cache deliberately when parallel work is involved. Anthropic notes that a cache entry becomes available after the first response begins. If five workers launch at exactly the same time, they may all miss the entry that none of them has created yet. Send one warm-up request first, then fan out. For an interactive coding assistant, the warm-up can be the first real request rather than a separate dummy call.

Fourth, make misses visible in development. In Anthropic responses, inspect cache_creation_input_tokens and cache_read_input_tokens; the documentation gives the total-input formula as cache_read_input_tokens + cache_creation_input_tokens + input_tokens. In Gemini, implicit caching is enabled by default on Gemini 2.5 and newer models, and the response exposes usage.total_cached_tokens. These fields belong in logs and dashboards, not in a troubleshooting document nobody checks.

The smallest useful test is a three-request sequence: send a fixed 10,000-token prefix with one question, send the same prefix with a different question, then change one tool description and send it again. You should see a write, a read, and then a miss or a new write. That sequence proves whether your serializer and breakpoint placement behave as expected. It is more useful than a generic latency benchmark because it tests the failure mode that creates the bill.

When caching is a bad deal

Do not cache short prompts just because the API exposes a switch. Anthropic says prompts below the model and platform minimum are processed without caching and may fail silently from the application's point of view. Google lists minimum input thresholds such as 4,096 tokens for Gemini 3.5 Flash and Gemini 3.1 Pro Preview, and 2,048 for Gemini 2.5 Flash and Pro. A 600-token system prompt is not a serious caching target.

Caching is also a poor fit when the prefix changes more often than it is reused. A retrieval system that injects a different document set into the first half of every request may write constantly and read almost never. Move volatile retrieval results after the stable instructions, or cache only the durable policy and tool layer. Do not call a changing prompt “cached” because one request reported a write.

Privacy and correctness still outrank the invoice. Cache only material that the provider and your data policy permit you to retain for the stated lifetime. Never place tenant-specific secrets in a shared prefix merely because it is large. Also remember that caching does not freeze model output. OpenAI explicitly notes that the model still computes a new response from the cached prefix, so nondeterministic requests are not guaranteed to return identical answers.

The practical decision is straightforward. Enable caching when a stable prefix is large, reused within the provider's TTL, and followed by enough requests to create real reads. Keep it off when the prompt is short, highly dynamic, or sensitive in a way your retention policy does not allow. Then watch the ratio of cache reads to writes for a week. If reads do not dominate, fix request structure before changing models.

Prompt caching is not an optimization you sprinkle over an agent at the end. It is a property of the request shape. Put stable context first, keep it stable, measure the read fields, and let the bill tell you whether the design is working.

Sources