Summary: Amazon Bedrock prompt caching snapshots a static request prefix after the first request so later requests can read it at up to a 90% input discount. Cache writes cost 25% more than standard input, or 2x under a one-hour TTL. Minimum token thresholds and cache scopes by AWS account and Region constrain when the optimization activates.
Most cost-optimization advice for LLM apps starts with trimming tokens or shrinking context. Yet when the same system prompt, document, or tool schema rides along with every request, you keep paying full input price for content the model has already processed. Amazon Bedrock’s prompt caching goes after that specific leak: snapshot the static prefix once, and later requests read it back at up to 90% off the input rate, with a faster time-to-first-token (TTFT).
The mechanics: cache points and TTLs
Caching in Bedrock is driven by a cachePoint marker in the Converse API. Whatever sits before that marker is snapshotted after the first request. A hit means the model skips reprocessing those tokens and generates from the cached state; a miss means it processes the full content and writes it to cache.
Four constraints shape how you use it:
- Scope: Cache entries are per AWS account and Region.
- Token thresholds: A checkpoint needs a minimum token count before it activates. Claude Sonnet 4.5 and 4.6 need at least 1,024 tokens; Opus models need 4,096.
- TTL: Entries expire according to the TTL you set. The default is 5 minutes; select models allow up to 1 hour.
- Syntax: The
cachePointsyntax is identical across supported model families, Anthropic Claude and Amazon Nova included.
Pricing lands in three token categories: cacheWriteInputTokens run 25% above standard input (or 2x under a 1-hour TTL), while cacheReadInputTokens come in 90% below it. Take a 10,000-token document queried with 10 different questions: the first request absorbs the write premium, and the next nine read at the discount — roughly 75% net savings on input tokens, provided every hit falls inside the TTL window.
Where the savings actually show up
The AWS Machine Learning Blog lays out six scenarios, basic through advanced. The first three are the everyday patterns:
- Message content caching: Place a
cachePointbetween a static document and the dynamic user question. That’s the RAG pattern — one reference body, many queries. - System prompt caching: Cache persona definitions and instructions across conversations. With a stable assistant system prompt, this is close to free money.
- Tool definition caching: Cache tool schemas for agentic workflows. Tool definitions seldom change between turns, which makes them a natural cache target.
The advanced scenarios cover mixed TTL caching (different lifetimes for different content tiers), tenant isolation for multi-tenant apps, and LangChain integration.
Implementation itself is straightforward. In Python with boto3, the content blocks are structured like this:
content = [
{"text": "<static document content>"},
{"cachePoint": {"type": "default"}},
{"text": "<user question>"}
]The cache point separates the stable prefix from the changing suffix: everything above it gets cached, everything below is processed normally on each call.
The tradeoff you’re signing up for
None of this is free. A cache write costs 25% more than a standard input token, so coming out ahead depends on repeated hits inside the TTL. Send one-shot queries with no shared prefix and caching will cost you more, not less.
TTL is the other lever. The default 5-minute window suits rapid-fire question sequences over the same document. The 1-hour option doubles the write cost in exchange for a longer hit window — useful for slower, session-based interactions. The AWS post also notes that cross-Region inference profiles can occasionally raise cache write frequency, since requests may route into different Regions where no cache entry exists.
This is the same infrastructure-level reasoning behind model caching on HyperPod: push repeated computation into a cache layer and the per-request cost drops. The difference is the level it operates on — prompt caching works over tokens, not model weights, so your integration point is prompt structure rather than the serving stack.
What to do next
Start by finding the largest stable prefix in your requests. For most apps that’s the system prompt or a long context document. Then measure how often that prefix repeats within a 5-minute window. If the answer is “often,” add a cachePoint and watch the cacheReadInputTokens metric.
If your prefix sits below the model’s minimum token threshold, caching never activates — you pay the write premium and get no read discount. The supplied AWS post uses Claude Sonnet 4.5 with a 1,024-token minimum, so a short system prompt won’t qualify. In that case, consider consolidating instructions or bundling tool definitions to cross the threshold.
Prompt caching is structural optimization, not a prompt-engineering trick. It rewards you for knowing exactly which part of a request is static and which part changes. Get that split right, and the cost curve bends in your favor without touching model quality.