TL;DR
Bedrock prompt caching works like caching on the direct APIs and bills like it, but the rules are set per model by AWS, and they are stricter than the ones you may have already learned.
The difference that costs real money: on Bedrock, Claude Opus 4.5, Opus 4.6, Sonnet 4.5 and Haiku 4.5 all require 4,096 tokens per cache checkpoint. On Anthropic's direct API, Sonnet 4.5 caches from 1,024. Same model, same prompt, four times the threshold, and when you fall below it nothing fails. The request succeeds, nothing is cached, and you pay full price without a single warning.
This guide covers what Bedrock does differently: the per-model minimums, the cachePoint syntax, the tools to system to messages invalidation chain, the response fields that tell you whether caching actually happened, and the cases where it is not available at all.
Running Claude or GPT on Bedrock and not sure the caching is working? We instrument this as part of every AI development build. The check takes minutes; the silent failure costs months.
Key Takeaways
- Cache checkpoint minimums on Bedrock are per model: 4,096 tokens for Claude Opus 4.5/4.6, Sonnet 4.5 and Haiku 4.5, against 1,024 for Sonnet 4.6 and Claude 3.7 Sonnet.
- Below the minimum there is no error. The request works, nothing caches, and only the usage fields reveal it.
- Checkpoints process in a fixed order, tools then system then messages, and changing an earlier section invalidates everything after it.
- The minimum is evaluated against the cumulative tokens across all three sections, not each section alone.
- Prompt caching on Bedrock is on-demand only. It does not work with batch inference.
- Cache hits do not count against your rate limits, which is a reason to cache even when the dollar saving is modest.
What is the same, so you can skip re-learning it
The mechanics are the ones covered in our full guide to prompt caching: the model's computed state for a stable prompt prefix is stored, later requests that share the prefix skip recomputation, reads bill at a discounted rate, and a time-to-live governs how long the cache survives between hits. The TTL resets on every successful hit. The break-even logic, where sparse traffic makes explicit caching cost more than it saves, applies unchanged.
What changes on Bedrock is everything around those mechanics: who sets the rules, what the thresholds are, how you mark the cache, and what you can combine it with. That is this page.
The minimums, and the trap inside them
Every cache checkpoint has a minimum token count, set per model, and the differences are large enough to change architecture decisions:
| Model on Bedrock | Minimum tokens per checkpoint | Max checkpoints | TTL |
|---|---|---|---|
| Claude Opus 4.5 | 4,096 | 4 | 5 min or 1 hour |
| Claude Opus 4.6 | 4,096 | 4 | 5 min |
| Claude Sonnet 4.5 | 4,096 | 4 | 5 min or 1 hour |
| Claude Haiku 4.5 | 4,096 | 4 | 5 min or 1 hour |
| Claude Sonnet 4.6 | 1,024 | 4 | 5 min |
| Claude 3.7 Sonnet | 1,024 | 4 | 5 min |
| GPT-5.6 family | 1,024 | 4 | 30 min |
| Amazon Nova | automatic for text prompts | n/a | n/a |
Two things in that table deserve a hard look.
First, the 4,096 rows. On the direct Anthropic API, Sonnet 4.5 caches from 1,024 tokens. Move the same workload to Bedrock and the threshold quadruples. A 2,500-token system prompt that cached happily on the direct API silently stops caching after the migration, and your bill rises for a reason no error message will ever surface.
Second, Haiku 4.5 at 4,096. Haiku is the routing tier, the model you send high-volume small tasks to. Small tasks have small prompts, and small prompts are exactly what a 4,096-token minimum excludes. The same interaction we flagged on the direct API is worse here: route to the cheap model and you may quietly lose the caching you sized the saving on, on the platform where the threshold is highest.
If your prefix lands just under a minimum, padding it up to the threshold is usually worth it. Reads bill at a tenth; a few hundred filler tokens that unlock the discount pay for themselves almost immediately.
How to mark the cache: cachePoint in the Converse API
Bedrock does not use Anthropic's cache_control field. In the Converse API you insert a cachePoint block after the content you want cached:
"messages": [
{
"role": "user",
"content": [
{ "text": "...your large stable context..." },
{ "cachePoint": { "type": "default" } }
]
}
]
The same block works inside system and tools, and you can spend your four checkpoints across all three fields. For the one-hour TTL on supported models, add "ttl": "1h" inside the cachePoint; omitted, it defaults to five minutes. One constraint carried over from the direct API: longer-TTL checkpoints must appear before shorter ones.
For Claude models, Bedrock also offers the simplified pattern: place a single checkpoint at the end of your static content, and the system looks back roughly 20 content blocks for the longest prefix an earlier request already wrote. The breakpoint placement trap applies identically here: put that checkpoint on a block that changes per request, a timestamp, the user's message, and you will write on every call and read on none.
The invalidation chain: tools, then system, then messages
Checkpoints process in a fixed order, and the order is a dependency chain. Changing content in an earlier section invalidates the cache for every section after it.
Modify a tool definition and you have invalidated tools, system and messages, the entire cache. Modify the system prompt and messages go with it. Only changes at the end of the chain, the messages, leave the earlier caches standing.
Two consequences worth engineering around:
- Tool definitions are the most expensive thing to touch. A one-character edit to a tool description re-bills your entire cached prefix at write rates. Version tool changes deliberately rather than letting them drift with deploys.
- The minimum is cumulative across sections. Bedrock evaluates the token threshold against tools plus system plus messages together, not per section. A 1,500-token system prompt that misses a 4,096 minimum alone can clear it once tool definitions are counted, which occasionally makes the bloated tool list weirdly useful. Do not treat that as a strategy; treat it as a reason your caching may behave differently after you trim the tool list.
The check that takes one minute
Because failure is silent, the only way to know caching is working is to read the response. The Converse API returns three fields:
cacheReadInputTokens: tokens served from cache this requestcacheWriteInputTokens: tokens written to cache this requestinputTokens: tokens that did neither
Total input is the sum of all three. The diagnosis table:
| What you see | What it means |
|---|---|
| Reads high, writes near zero | Caching is working. This is the goal state |
| Writes on every request, reads near zero | Your checkpoint sits on content that changes. You are paying premiums for nothing |
| Both zero, always | You are below the model's minimum, or the checkpoint is missing. Nothing is cached |
Alert on the second and third states. They are invisible on the invoice, which only shows the total climbing.
What Bedrock caching does not do
Three limits that catch teams after the architecture is already committed:
- No batch inference. Prompt caching works with on-demand inference only. If you move non-urgent work to the Batch API for the 50% discount, that work leaves the cache behind. The discounts do not stack on Bedrock, so price both paths before assuming batch plus cache.
- Cross-region inference can raise write counts. Bedrock's cross-region routing selects the optimal region per request, and at high demand your requests can land on machines without your cache, producing extra writes. The feature is worth keeping; the extra writes are worth knowing about when the usage fields look odd at peak.
- Cache isolation is organisation-level. The direct Anthropic API isolates caches per workspace; Bedrock isolates per organisation. Different teams in one org sharing identical prefixes can share cache hits, which is usually a pleasant surprise rather than a problem, but it matters if you attribute costs per team from the usage fields.
One genuine advantage to weigh against all of this: cache reads do not count against your rate limits. On a workload that brushes its throughput ceiling, caching buys headroom as well as discount, and that can be worth more than the dollar saving.
Frequently asked questions
What is the minimum token count for Bedrock prompt caching?
It is set per model. Claude Opus 4.5, Opus 4.6, Sonnet 4.5 and Haiku 4.5 require 4,096 tokens per cache checkpoint on Bedrock, while Claude Sonnet 4.6, Claude 3.7 Sonnet and the GPT-5.6 family require 1,024. Below the minimum the request succeeds and nothing is cached, with no error returned, so verify with the usage fields rather than assuming.
How do I enable prompt caching in the Bedrock Converse API?
Insert a cachePoint block of type default after the stable content you want cached, inside messages, system or tools. You get up to four checkpoints per request, and supported Claude models accept a ttl of 1h for the one-hour cache. There is no account-level switch; caching is controlled entirely by where you place the blocks.
Why is my Bedrock cache not working?
The three usual causes, in order: your prefix is below the per-model minimum, which fails silently; your checkpoint sits on content that changes per request, so the hash never repeats and you write without ever reading; or something earlier in the tools, system, messages chain changed and invalidated everything after it. The cacheReadInputTokens and cacheWriteInputTokens fields in the response distinguish all three cases.
Does Bedrock prompt caching work with batch inference?
No. Prompt caching on Bedrock is supported for on-demand inference only, so work you move to batch processing for its discount gives up cache reads entirely. The two discounts do not combine, which means high-volume asynchronous workloads should be priced both ways before you commit an architecture to either.
Is caching cheaper on Bedrock or on the direct Anthropic API?
The pricing structure is comparable, discounted reads against a possible write premium, so the bill difference is usually decided by the thresholds rather than the rates. The direct API caches Sonnet 4.5 from 1,024 tokens where Bedrock requires 4,096, so workloads with mid-sized prompts can cache on the direct API and silently fail to cache on Bedrock at the same prompt length.
