Prompt Caching and Batch Processing: the 5-Minute Rule That Decides Whether Caching Pays
Prompt caching pays only when the same prompt prefix is read again within five minutes, because Anthropic charges 1.25x base input to write a five-minute cache entry and 0.1x to read one. Batch processing charges 50 percent of standard rates but is unavailable on Amazon Bedrock. Pexon measures the read-to-write ratio on real traffic before promising a saving.
Two levers, one bill, and neither is free to switch on
Prompt caching and batch processing are not alternatives and they do not compete. Caching changes what you pay for input you send more than once. Batching changes what you pay in exchange for giving up latency. Anthropic's pricing documentation states the two multipliers stack, so a workload can be eligible for both, one, or neither — and which of those four it is has nothing to do with how much you spend and everything to do with the shape of your traffic.
The multipliers are public and they are the only numbers on this page that come from Anthropic. A five-minute cache write costs 1.25x the base input rate, a one-hour cache write costs 2x, and a cache read costs 0.1x. Batched requests are billed at 50 percent of standard rates on both input and output.
Everything else — whether those multipliers turn into a smaller invoice — depends on your read-to-write ratio and on how much of your volume tolerates a 24-hour turnaround. We have not published a percentage for either, and the last section explains what we intend to measure instead.
One structural point before the mechanics, because it caps how much caching can ever be worth: every current Claude model prices output tokens at exactly five times input tokens. Caching touches input only. Batching is the sole lever of the two that reaches the expensive half of the bill.
The five-minute window is the whole caching decision
A cache entry lives five minutes by default, and Anthropic's documentation states that it is refreshed for no additional cost each time the cached content is used. That single sentence is the mechanic that matters. A prefix read at least once every five minutes stays warm indefinitely at the 0.1x read rate. A prefix read less often than that expires between calls and is rewritten at 1.25x, every time.
Convert the five minutes into a business unit and the decision rule writes itself: the workload has to produce at least twelve requests an hour against the same prefix, sustained, for the default cache to hold. Not twelve requests an hour in total — twelve against that prefix, because the entry is keyed to the exact prefix and a per-customer system prompt is a different entry per customer.
The one-hour lifetime buys a wider window at 2x the write price, and Anthropic states the break-even plainly: caching pays after one cache read at the five-minute duration, and after two reads at the one-hour duration. Below that, you have paid a premium for nothing.
Which produces the failure mode nobody budgets for. A workload that writes a cache entry and never reads it inside the lifetime pays 1.25x for input that would otherwise have cost 1x. Enabling prompt caching on a low-frequency queue with a long system prompt does not reduce the bill by a disappointing amount. It raises it by a quarter of the prefix cost, silently, on every single case.
Three more mechanics that decide whether the feature is doing anything at all:
- The minimum cacheable length is model-specific and Anthropic publishes it per model, from 512 tokens on the newest Opus-class models up to 4,096 on Haiku-class ones. A request under the minimum is processed without caching and no error is returned — so you can ship a cache_control block, see a normal response, and be caching nothing.
- There are at most four explicit cache breakpoints per request. If all four are already taken by block-level breakpoints, there is no slot left for automatic caching and the API returns a 400.
- A cache entry only becomes available after the first response begins. Fanning ten parallel requests at a cold prefix produces ten cache writes, not one write and nine reads. Anthropic's guidance is to wait for the first response before sending the rest.
- Automatic caching — the single top-level cache_control field — is available on the Claude API, Claude Platform on AWS, Google Cloud and Microsoft Foundry, but not on Amazon Bedrock, where you place explicit breakpoints yourself.
What invalidates the cache, in the order it cascades
| The change | What it invalidates |
|---|---|
| Tool definitions — names, descriptions or parameters | Invalidates tools, system and messages. The whole cache. |
| Toggling web search or citations | Both modify the system prompt, so system and messages go. |
| Switching between fast and standard speed | Invalidates system and message caches. |
| tool_choice, and adding or removing an image anywhere in the prompt | Message blocks only. |
| The thinking configuration and the output effort setting | Always invalidates message blocks; the effect on tool and system caches is model-specific. |
Invalidation runs top-down through three levels — tools, then system, then messages — and a change at one level invalidates that level and everything below it. This is the part that turns a working cache into a rounding error in production, because the things that trigger it are ordinary product decisions rather than mistakes.
The expensive one is first in the list. Modifying any tool definition, including a description or a parameter name, invalidates the entire cache. A tool registry that assembles a per-user set of tools, or a team that ships prompt tweaks daily, is a team whose cache is cold most of the time and whose caching line therefore reads 1.25x rather than 0.1x.
Anthropic's documented triggers, at the level each one hits.
Batch processing: fifty percent is a rate, not a saving
The Message Batches API bills at 50 percent of standard prices on input and output, and that is a discount on the rate rather than a reduction of your bill. Your bill falls by half only on the share of volume you actually move into batches, which is why the interesting question is never the discount but the eligibility.
The limits are hard and worth knowing before an architecture depends on them. A batch holds at most 100,000 requests or 256 MB, whichever is reached first. Most batches finish within an hour. Results become available when every request has completed or after 24 hours, whichever comes first, and a batch that has not completed inside 24 hours expires. Requests that expire or are cancelled are not billed. Results stay downloadable for 29 days after creation.
Results come back in arbitrary order. Anthropic is explicit that the ordering does not match submission and that custom_id is the only correct way to match a result to its request — which sounds trivial and is the single most common reason a batch pipeline produces silently mismatched output.
A short list of parameters is rejected in a batch: stream, speed, store and previous_thread_event_id, the cache_hint and context_hint routing hints, and max_tokens: 0. That last one is the cache pre-warming call, and Anthropic's stated reason is worth reading twice — an ephemeral cache entry written during batch processing would likely expire before the follow-up request runs.
Caching and batching do combine, and the discounts stack. But because batch requests are processed concurrently and in any order, cache hits inside a batch are best-effort. Anthropic's own documentation quotes observed hit rates ranging from 30 to 98 percent depending on traffic patterns. That is their figure, not ours, and a range that wide is a description of variance rather than a forecast you can put in a business case. If you batch with shared context, Anthropic's own tip is to use the one-hour lifetime, because batches routinely take longer than five minutes to process.
The verification command below is the first thing we run, and it costs nothing: token counting is free and rate-limited separately from message creation.
# Mechanics verified against Anthropic's own documentation, 2026-08-04:
# https://platform.claude.com/docs/en/docs/build-with-claude/prompt-caching
# https://platform.claude.com/docs/en/docs/build-with-claude/batch-processing
# 1) Is the prefix even long enough to cache? Free, and it explains most
# "we turned caching on and nothing happened" tickets.
curl -s https://api.anthropic.com/v1/messages/count_tokens \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"system": "<paste the real system prompt, not a demo one>",
"messages": [{"role": "user", "content": "ping"}]
}' | jq .input_tokens
# Compare against the per-model minimum: 512 tokens on the newest
# Opus-class models, up to 4,096 on Haiku-class ones.
# 2) Send the real request twice, 60 seconds apart, and read the only two
# fields that decide anything. Write is billed 1.25x, read 0.1x.
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 512,
"cache_control": {"type": "ephemeral"},
"system": "<the same system prompt, byte for byte>",
"messages": [{"role": "user", "content": "<a real case>"}]
}' | jq '{
write: .usage.cache_creation_input_tokens,
read: .usage.cache_read_input_tokens,
plain: .usage.input_tokens
}'
# 3) Effective input multiplier over a measurement window. Sum the three
# fields across every request, then:
# (plain + 1.25*write + 0.1*read) / (plain + write + read)
# Below 1.0, caching is paying for itself.
# Above 1.0, caching is costing you money on this workload.Which lever applies to which workload
| Workload | Caching | Batching | The constraint that decides it |
|---|---|---|---|
| Coding agent, several turns per minute | Yes — the prefix is re-read well inside five minutes | No — the work is interactive | Tool definitions must stay byte-identical across turns |
| Overnight extraction over tens of thousands of files | Only with the one-hour lifetime, and best-effort inside a batch | Yes — this is the case the Batches API exists for | 100,000 requests or 256 MB per batch, results returned out of order |
| Support triage, one case every ten minutes | No — the entry expires between cases and each write costs 1.25x | No — the answer is needed inside the conversation | Inter-arrival gap longer than the five-minute cache lifetime |
| Retrieval over a stable corpus, bursty traffic | Yes during a burst, no between bursts | Only for the offline evaluation runs | Retrieved chunks change per query, so only the prefix is cacheable |
| EU-resident workload on Amazon Bedrock | Explicit breakpoints only — automatic caching is not available there | Not available at all | Anthropic lists Message Batches as unsupported on Bedrock |
Five workload shapes cover most of what we are asked about, and the answer differs for every one of them. Read the third column first — the constraint is what decides the row, not the size of the spend.
Row three is the one that surprises people, because a support queue feels high-volume from the inside. Forty cases spread over a working day is one every twelve minutes, the cache entry is dead before the next case arrives, and every case pays the 1.25x write.
Row five is a decision that was already made elsewhere. Anthropic's Bedrock integration page lists Message Batches among the unsupported API endpoints, so a company that chose Bedrock for EU data residency has given up the larger of the two levers without anyone recording it as a cost. That is not an argument against Bedrock. It is an argument for pricing the trade-off at the time it is made rather than discovering it during a FinOps review eighteen months later.
Where the savings are not
Both features are input-side or throughput-side optimisations, and there is a category of cost neither of them touches. Naming that category is more useful than another paragraph about multipliers.
Output tokens are the first. Every current Claude model prices output at five times input, and caching does nothing whatsoever to output. A workload whose bill is dominated by long generated answers will see almost nothing from caching, however perfect the hit rate looks in a dashboard.
Turns are the second, and they are usually the real driver. An agent that takes nine tool-calling turns instead of four does not merely cost more than twice as much — each extra turn resends a context window that has grown since the last one, and it generates output tokens of its own. No multiplier recovers that. Cutting a turn out of the loop beats any caching configuration, which is why we look at turn counts before we look at cache statistics.
The third is the one that ends the conversation: caching and batching are configuration, and configuration does not survive a team that has not decided its prompt is stable. If the system prompt changes twice a week and the tool registry is assembled per user, the cache is cold by design and the honest recommendation is to fix the prompt architecture first and revisit the multipliers afterwards.
There is also a real argument for doing none of this. If the total spend is four figures a month, the engineering time to instrument, measure and maintain a caching strategy costs more than the tokens it saves, and the correct answer is to leave both features off and revisit at ten times the volume. We say that to people who expected a different answer, and it is right more often than a consultancy has any commercial incentive to admit.
The benchmark we are going to run, and why there is no percentage on this page
We have not published a savings figure because we have not yet run the measurement on a customer workload, and a number without a workload attached is worthless — it tells you about someone else's traffic shape, not yours. Anthropic's marketing figures have the same problem for the same reason.
The measurement we intend to run has a name, the prefix-stability benchmark, and it takes fourteen days of instrumented traffic rather than a lab test. It answers three questions in order: how stable is the prefix, how often is it re-read, and how much of the volume could have waited until tomorrow. Only the third one is a business decision; the first two are arithmetic.
When we have run it across enough engagements to say something that generalises, the number appears on this page with the workload described next to it. Until then, the mechanics above are the defensible part, and they are enough to tell you whether the feature can help you at all.
Six steps, in this order
- Log cache_creation_input_tokens, cache_read_input_tokens and input_tokens per request for fourteen days, tagged by prefix hash and workload. Without the prefix hash the aggregate hides the only thing that matters.
- Compute the inter-arrival gap distribution per prefix. The share of gaps under five minutes is the ceiling on what caching can achieve, before any tuning.
- Compute the effective input multiplier from step one. Above 1.0 means caching is currently costing money and should be switched off on that workload today, not optimised.
- Count how many distinct prefixes exist. One prefix per customer or per tenant divides the hit rate by the number of tenants, and that is usually the finding that kills the business case.
- Classify the volume by latency tolerance, in cases per day, not in percentages. Anything that can wait until the next morning is batch-eligible; everything else is not, regardless of how attractive the 50 percent rate looks.
- Re-run the token count against the model you actually intend to call. Anthropic documents that Claude 4.7 and later use a newer tokenizer producing roughly 30 percent more tokens for the same text, so counts taken on an older model are not a forecast for a newer one.
Questions we get asked about Claude caching and batching
How long does a Claude prompt cache entry live?
Five minutes by default, and every cache hit refreshes that window at no extra charge, so a prefix that is read at least once every five minutes stays warm indefinitely. A one-hour lifetime is available by passing ttl: "1h" on the cache_control block, and Anthropic prices that write at 2x base input instead of 1.25x.
Can prompt caching make a Claude bill larger?
Yes, and it is the failure mode nobody plans for. A five-minute cache write costs 1.25x the base input rate and a read costs 0.1x. A workload that writes a cache entry and never reads it inside the lifetime pays 1.25x for input it would otherwise have paid 1x for. Low-frequency queues with long system prompts are the usual victims.
What invalidates a Claude prompt cache?
Anthropic documents a cascade in the order tools, then system, then messages: changing any tool definition invalidates everything below it, toggling web search or citations invalidates system and messages, and changing tool_choice, adding or removing an image, or altering the thinking or effort configuration invalidates message blocks. Adding one tool to a registry therefore rebuilds the entire cache for every user.
Why is nothing cached even though we set cache_control?
Most likely the prefix is shorter than the model's minimum cacheable length, which Anthropic documents per model and which ranges from 512 tokens on the newest Opus-class models to 4,096 on Haiku-class ones. A request below that minimum is processed without caching and returns no error, so the only way to notice is to read cache_creation_input_tokens and cache_read_input_tokens in the usage block.
Does the Message Batches API work on Amazon Bedrock?
No. Anthropic's Bedrock integration page lists Message Batches among the API endpoints that are not supported, alongside the Files API, server-side tools and the Usage and Cost API. A company that chose Bedrock for EU data residency has therefore already given up batching, which matters because batching is the larger and more predictable of the two cost levers.
What are the hard limits on a Claude message batch?
A batch holds at most 100,000 requests or 256 MB, whichever comes first. Most batches finish inside an hour, results become available when every request has completed or after 24 hours, and a batch that has not completed within 24 hours expires. Requests that expire or are cancelled are not billed, and results stay downloadable for 29 days after creation.
Can prompt caching and batch processing be combined?
Yes, and Anthropic states the two discounts stack. The catch is that batch requests are processed concurrently and in any order, so cache hits inside a batch are best-effort rather than guaranteed. Anthropic's own documentation quotes observed hit rates anywhere from 30 to 98 percent depending on traffic shape, which is a range wide enough that it cannot be used as a forecast.
How much will caching and batching save us?
We will not quote a percentage, because we have not yet run the measurement on a customer workload and every published figure is either a vendor headline or someone else's traffic. The multipliers are public and fixed; the saving depends entirely on your read-to-write ratio and how much of your volume tolerates a 24-hour turnaround. Both are measurable in two weeks of instrumented traffic.
Next step
Measure the two ratios before you commit to either lever
Two weeks, fixed price: fourteen days of instrumented traffic, the effective input multiplier per workload, the share of volume that is genuinely batch-eligible, and a written recommendation that may well be to leave both features off. The measurement is yours to keep whether or not we build anything.