Amazon Bedrock prompt caching: how it works, what it saves, and why it misses.

IWhat Amazon Bedrock prompt caching is

You pay for input tokens on every call. Caching stops you paying full price for the part that never changes.

A support assistant may send the same 4,000-token system prompt with every message. A document app re-sends the same contract with each question. An agent re-sends its tool schemas on every turn. Without caching, each call pays the full input rate for that repeated block.

With caching, Bedrock keeps the processed prefix for a short time. The next call that starts with the exact same tokens reads it from cache. Those tokens bill at the model's cache-read rate, and the answer starts sooner because the model does not reprocess the prefix. AWS describes the feature as reducing both response latency and input token cost.

IIHow explicit caching works

Five rules decide whether a call hits the cache.

• Order: tools, then system, then messages: Checkpoints are processed in that order and the sections are chained. Changing the tools invalidates the system and messages cache. Put stable content first and place checkpoints right after it.
• A minimum prefix length: The whole prompt prefix before a checkpoint must meet the model's minimum, which ranged from 512 to 4,096 tokens on 10 October 2026. Below it, the call still works but nothing is cached.
• Up to four checkpoints: Claude models accept up to 4 checkpoints per request across system, messages and tools. Amazon Nova models accept checkpoints in system and messages and cache up to 20K tokens.
• A TTL that resets on each hit: Many models keep the cache for 5 minutes. Newer Claude models (Sonnet 4.5, Haiku 4.5, Opus 4.5 and later) also offer a 1-hour TTL; you set "ttl": "1h" on the checkpoint. OpenAI GPT-5.6 and later keep cache for at least 30 minutes.
• Exact matching: The cached prefix must be identical, token for token. One changed character before the checkpoint means a miss.

For Claude, Bedrock also offers simplified cache management: put one checkpoint at the end of your static content and Bedrock looks back about 20 content blocks for the longest cached match. The Converse response reports cacheReadInputTokens and cacheWriteInputTokens, so you can see what hit. Details are on the prompt caching page.

IIIWhich models support prompt caching

Check the model card. The list grows.

On 10 October 2026 the AWS docs listed explicit caching for current Anthropic Claude models (Claude 5.x and 4.x, Claude 3.7 Sonnet), Amazon Nova Micro, Lite, Pro and Nova 2 Lite, and OpenAI GPT-5.6 and later (through the Responses API). Claude models also support implicit caching. Nova offers implicit caching for all text prompts. OpenAI GPT-5.5 and earlier cache prefixes of 1,024 tokens or more automatically, with no cache-write fee.

Caching is available in every Region where a supported model runs. It applies to on-demand inference only; the batch inference API does not support it.

IVWhere prompt caching pays off

Any workload that resends a large, stable block within the TTL.

• Long system prompts: Voice, policies, formatting rules and safety instructions that are the same on every call.
• Agents with many tools: Tool schemas resent on every turn of an agent loop. Agents fire many turns, so the saving adds up.
• Questions over one document: A user asks several questions about the same contract, codebase or report.
• Multi-turn chat: The system prompt plus the conversation so far forms a growing stable prefix.
• Few-shot examples: A fixed set of examples in front of classification or extraction prompts.

VThe savings math, with a worked example

Caching costs a little extra once, then saves on every reuse.

Rates differ by model, so use ratios. On the pricing page example for Claude 3.5 Sonnet v2 (checked 10 October 2026), a cache write cost 1.25 times the normal input price and a cache read cost one tenth of it. AWS states the same 1.25 write rate for OpenAI GPT-5.6 and later.

Worked example with those ratios: 1,000 calls inside the TTL, each with a 4,000-token stable prefix and a 500-token new question. Without caching: 4.5 million input tokens at the full rate. With caching: one write of 4,000 tokens at 1.25 (5,000 token-equivalents), 999 reads of 4,000 tokens at 0.1 (about 400,000), plus 500,000 fresh tokens. That is about 905,000 token-equivalents, roughly 80% less input cost. Output tokens are unchanged.

The same math shows when caching does not pay: a prefix read once or not at all within the TTL costs more than no cache, because of the write premium.

VIWhy your cache misses, and how to fix it

Most low hit rates come from a few mistakes.

• Dynamic content near the top: A timestamp, request ID, user name or date in the system prompt changes the prefix on every call. Move it after the checkpoint.
• Wrong order: Only the block from the first token to the checkpoint is cached. Put the volatile user message last.
• Unstable serialization: JSON tool definitions with changing key order or whitespace produce different tokens. Serialize them the same way every time.
• A cold cache: Sparse traffic lets the cache expire between calls. Use the 1-hour TTL where the model supports it, or accept that low-traffic paths will not benefit.
• A prefix below the minimum: The call works, but nothing is cached. Check the model's minimum.
• No measurement: Log cacheReadInputTokens and cacheWriteInputTokens on every call and track the hit rate.

VIIHow caching combines with other Bedrock cost levers

Caching lowers the price of repeated input. Other levers change the model or the pricing mode.

• Works with: Converse and ConverseStream, InvokeModel and InvokeModelWithResponseStream, cross-Region inference (busy periods can mean more cache writes) and Prompt management.
• Does not work with: The batch inference API. Caching is for on-demand calls. Use batch, which AWS prices at 50% below on-demand for select models, for bulk jobs instead.
• Rate limits: AWS says cached input tokens do not count against the input-tokens-per-minute quota for OpenAI models, and that cache hits are not deducted from your rate limit in its Claude guidance. That can help on busy apps. See Bedrock quotas.
• Model choice: Pick the cheapest model that is good enough first, then cache its repeated context. See Intelligent Prompt Routing.

VIIIWho can file AWS funding for a Bedrock build

There are two kinds of AWS money for a Bedrock build. A partner files one. You apply for the other yourself.

Partner-filed funding. An AWS consulting partner can file POC (proof of concept) funding to test a Bedrock workload, whether or not you run on AWS today. If you already run on AWS and are adding new AI work, the partner can file incremental workload (IW) funding instead. For startups this is often $50K to $150K. Depends on the workload; AWS approves. The work has to be real, and the partner has to be the one doing it.

AWS Activate, which you apply for yourself. Activate Founders gives $1,000 to start, up to $5,000, with no investor needed. Activate Portfolio gives up to $200,000 if your VC, accelerator or angel group is an Activate Provider and gives you its Org ID. A consulting partner cannot apply for Activate on your behalf. AWS made Activate credits usable for third-party models on Bedrock in April 2024.

For most startups without a VC, the partner route is the larger of the two, and caching makes whatever funding you get last longer. CloudRoute matches you with one vetted AWS partner for free. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.