Amazon Bedrock Prompt Caching: How It Works, Supported Models, Minimum Tokens, 5-Minute and 1-Hour TTL, Pricing, Python Examples and Why Your Cache Misses

Amazon Bedrock prompt caching stores the repeated beginning of your prompts (a long system prompt, tool definitions, a document you ask many questions about) so later requests read it from the cache at a much lower price and with less delay. There are two kinds. Implicit caching happens automatically on supported models, best effort. Explicit caching lets you mark where the reusable part ends with a cache checkpoint: a {"cachePoint": {"type": "default"}} block in the Converse API, cache_control in Anthropic's InvokeModel format, or prompt_cache_breakpoint for OpenAI's GPT-5.6 and later. The part before a checkpoint must reach a model-specific minimum, from 512 to 4,096 tokens. You get up to 4 checkpoints per request, and the cache lives 5 minutes after its last use (1 hour on supported Anthropic models, 30 minutes on newer OpenAI models). Cache writes can cost more than normal input and cache reads cost far less; the response's cacheReadInputTokens and cacheWriteInputTokens show what happened. Below: how it works, supported models, Python examples for Converse, InvokeModel and OpenAI models, pricing with worked numbers, the 1-hour TTL, LangChain's middleware, and every reason a cache misses.

Ethan's warranty assistant for Jake's computer shop sends the same 9,000-token warranty policy with every question the front desk asks, about 300 times a day. Each question repeats the policy in full, so 90% of every bill was the same text, paid for again and again. Prompt caching is Bedrock's answer to exactly that. Adding one line to the request cut the input cost of those calls by roughly 80% and made answers start noticeably sooner. This page explains that line, and the handful of rules that decide whether it works.

New to Bedrock? Our plain-English Bedrock explainer covers the service, and the cards below cover the rest.

How Bedrock prompt caching works

When a model reads a prompt, it turns every token into an internal working state before it writes anything. For a 9,000-token policy, that reading step is most of the work and most of the cost. Prompt caching keeps that working state for the start of the prompt, so the next request that begins with exactly the same text can skip re-reading it.

Three ideas cover the whole feature:

• It caches a prefix. Only the beginning of a prompt can be reused, and it must match exactly, character for character, up to the checkpoint. Put what never changes first and what changes (the user's question) last.
• It has a short life. A cached prefix lives for its TTL, usually 5 minutes, and every hit resets the clock. A busy chatbot keeps its cache warm all day; one question an hour finds it expired every time.
• It changes the price of input tokens. Tokens read from the cache are billed at a much lower cache-read rate; tokens written to the cache can cost a little more than normal input on some models. The first request pays to fill the cache; the following ones save.

Implicit vs explicit. With implicit caching, Bedrock and the model try to reuse matching prefixes automatically, with no change to your request; it is best effort, so hits are not guaranteed. With explicit caching, you mark the end of the reusable part with a checkpoint, which makes it eligible for caching and gives you control over what is cached. Even explicit caching does not guarantee a hit for every request; the response tells you what actually happened.

Jake: "So the computer remembers the warranty policy for five minutes?"

Ethan: "It remembers having read it. As long as someone asks something every five minutes, it never has to read it from scratch again."

Supported models, minimums, checkpoints and TTL

Explicit caching is supported by these model families on Bedrock as of October 2026:

Some details that matter in practice:

• The minimum is cumulative. It counts everything before the checkpoint across tools, system and messages together, not just the block the checkpoint sits in. You can place checkpoints closer together than the minimum, as long as the total before each one meets it.
• Too short is silent. A checkpoint placed before the minimum is reached does not cause an error; the request simply runs uncached. If your savings are zero, check this first.
• Nova caches text up to 20,000 tokens and also does implicit caching for all text prompts, so repeated beginnings can speed up even without checkpoints.
• Older OpenAI models (GPT-5.5 and earlier) cache automatically for prefixes of 1,024 tokens or more, with no write fee and no setup.
• Not every model supports it. Check the model's card in the Bedrock console; our model IDs list covers the rest of each model's details.

Caching works with on-demand calls through Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream, with cross-Region inference profiles, and in Bedrock Prompt Management. It does not apply to batch inference jobs, which have their own discount instead.

Prompt caching with the Converse API (Python)

The Converse API uses the same cachePoint block for every supported model. Place it right after the static content. Here is the shop's warranty assistant with Amazon Nova Pro:

import boto3

brt = boto3.client("bedrock-runtime", region_name="us-east-1")
POLICY = open("warranty_policy.txt", encoding="utf-8").read()   # about 9,000 tokens

def ask(question: str):
    resp = brt.converse(
        modelId="us.amazon.nova-pro-v1:0",
        system=[
            {"text": "You answer warranty questions for a computer repair shop. "
                     "Use only the policy below and quote the section you rely on.\n\n" + POLICY},
            {"cachePoint": {"type": "default"}},          # everything above is cacheable
        ],
        messages=[{"role": "user", "content": [{"text": question}]}],
        inferenceConfig={"maxTokens": 500, "temperature": 0},
    )
    usage = resp["usage"]
    print("input:", usage["inputTokens"],
          "cache read:", usage.get("cacheReadInputTokens", 0),
          "cache write:", usage.get("cacheWriteInputTokens", 0))
    return resp["output"]["message"]["content"][0]["text"]

ask("Is a cracked screen covered on refurbished laptops?")   # first call: cache write
ask("How long is the battery warranty?")                       # within 5 minutes: cache read

The first call prints a large cache write number and the second a large cache read, with input showing only the few dozen tokens of the new question. That is the whole effect: the policy is paid for once at the write price, then at the read price for every question while the cache stays warm.

Checkpoints can also go in the tools list (after the last tool definition) and in messages (after a long document or image the user sent), which is how multi-turn chats keep earlier turns cached as the conversation grows.

The order rule. Bedrock processes cache checkpoints in the order tools, then system, then messages, and each section builds on the one before. Changing anything earlier invalidates everything after it: edit one tool description and the cached system prompt and messages are gone too. Keep tools and the system prompt stable, and put the changing parts at the end.

Reading the usage numbers

Every Converse response with caching includes:

• cacheReadInputTokens: tokens served from the cache, billed at the cache-read rate.
• cacheWriteInputTokens: tokens written into the cache by this request, billed at the cache-write rate.
• cacheDetails: which TTL the written tokens used.
• inputTokens: only the tokens that were neither read from nor written to the cache.

That last point catches people out. With caching on, inputTokens drops dramatically, and it is tempting to read that as the whole prompt. The real total is:

total input tokens = inputTokens + cacheReadInputTokens + cacheWriteInputTokens

Log all three from day one. A healthy cached workload shows one write followed by many reads; a pattern of writes on almost every request means the cache keeps missing, and the reasons are listed further down.

Jake: "Why does the first question cost more than without the cache?"

Ethan: "Writing the policy into the cache costs a bit extra, once. Every question after that reads it for a fraction of the price. By the third question we're ahead."

Prompt caching pricing, with worked numbers

Caching changes how input tokens are priced, per model:

• Cache reads cost a fraction of the normal input price. For Anthropic's models, a cache read is about one tenth of the standard input rate.
• Cache writes can cost more than normal input. For Anthropic's models, a 5-minute cache write is about 1.25 times the input rate, and 1-hour writes cost more again. OpenAI's GPT-5.6 and later bill writes at 1.25 times; GPT-5.5 and earlier have no write fee.
• Output tokens are unaffected. Caching saves on reading, not on writing answers.

Each model has its own cache-read and cache-write rates, listed alongside its normal ones, so check yours before you estimate. To see the effect, take the shop's numbers with an illustrative model priced at $2.00 per million input tokens, a 9,000-token cached policy, and 300 questions a day of about 50 tokens each:

That is the best case, with the cache warm all day. In reality the shop is quiet before 10 a.m. and at lunch, the cache expires, and the next question pays for a fresh write. Ethan's real saving came to about 80% of input cost, not 90%, which is typical: the busier and steadier the traffic, the closer you get to the maximum. Our Bedrock pricing guide covers the other levers that stack with this one.

The second saving: rate limits. On Anthropic's and OpenAI's models, cache hits are not counted against your input-tokens-per-minute quota. If your workload keeps hitting "Too many requests", caching can matter as much for your throughput as for your bill.

When prompt caching is worth it, and when it is not

Caching pays off when your requests share a long, unchanging beginning and arrive often enough to keep the cache warm. You will save the most if:

• Your system prompt or instructions run to thousands of tokens and rarely change.
• You ask many questions about the same document, manual, contract or codebase.
• You run an agent whose tool definitions and instructions repeat on every step.
• Your chat conversations run to many turns, so earlier turns repeat with each new message.
• Your traffic is steady, at least one request every few minutes during working hours.

It does little or nothing for you when:

• Your prompts are short, below the model's minimum.
• Every request is different from the first token, such as one-off summaries of different documents.
• Your requests are rare, so the cache expires between them and you pay the write price each time.
• You run the work as a batch job, which uses its own discount instead.

If you are unsure, turn it on for one workload, log the cache fields for a day, and compare what you paid with what you would have paid. The numbers decide in an afternoon.

Prompt caching vs Bedrock's other cost levers

Caching is one of several ways to cut a Bedrock bill, and they combine. Here is where each fits, so you can pick the right one for each workload:

For an interactive assistant like the shop's, the winning combination is usually the cheapest model that answers well enough, compact answers, and prompt caching on the shared instructions. For overnight jobs, batch inference replaces caching entirely; our batch inference guide covers that side.

The 5-minute cache and the 1-hour option

Every cache entry lives for its TTL (time to live) after its last use, and each hit resets the timer. The default is 5 minutes. Anthropic's supported models also offer a 1-hour TTL, set on the checkpoint:

{"cachePoint": {"type": "default", "ttl": "1h"}}

When is the 1-hour cache worth its higher write price?

• Keep the 5-minute cache when the same prefix is used more often than every five minutes. It refreshes on every hit at no extra charge, so it never expires on a busy day.
• Use the 1-hour cache when requests arrive less often than every five minutes but more often than hourly: a user who reads an answer for ten minutes before replying, an agent step that takes longer than five minutes, or a document someone queries a few times an hour.
• Use it when first-answer speed matters after a pause, since a hit after eight minutes is fast while a miss means re-reading everything.

Two rules apply. You can mix 1-hour and 5-minute checkpoints in one request, but the longer TTL must come first. And for models that only support the 5-minute TTL, such as Nova, leave the ttl field out entirely: including it can cause a ValidationException. OpenAI's newer models instead keep caches for at least 30 minutes, set with prompt_cache_options.ttl.

Caching a growing conversation

In a chat, every new message resends the whole conversation so far. Without caching, turn 20 pays for turns 1 to 19 again. With caching, you can move a checkpoint forward as the conversation grows, so each request reads the earlier turns from the cache and pays full price only for the newest ones. Here is how you set that up:

1. Cache the fixed part once: put a checkpoint after the system prompt (and tools), as in the example above.
2. Add a second checkpoint at the end of the conversation history, that is, after the last assistant reply and before the user's new message.
3. Move that second checkpoint forward every turn, so it always sits at the end of the history you are resending.
4. Keep the history identical between turns. Trimming, reformatting or summarizing earlier messages on the fly changes the prefix, and the cache misses.
5. When the conversation gets very long, summarize it once into a new, shorter history and accept a single cache rewrite, rather than editing it a little on every turn.

def chat_turn(history: list, user_text: str):
    # history holds earlier {"role": ..., "content": [...]} messages, unchanged
    msgs = [dict(m) for m in history]
    if msgs:
        last = msgs[-1]
        last["content"] = last["content"] + [{"cachePoint": {"type": "default"}}]
    msgs.append({"role": "user", "content": [{"text": user_text}]})
    resp = brt.converse(
        modelId="us.amazon.nova-pro-v1:0",
        system=[{"text": "You are the shop's warranty assistant.\n\n" + POLICY},
                {"cachePoint": {"type": "default"}}],
        messages=msgs,
        inferenceConfig={"maxTokens": 500},
    )
    reply = resp["output"]["message"]
    history += [{"role": "user", "content": [{"text": user_text}]}, reply]
    return reply["content"][0]["text"]

The function adds the checkpoint to a copy of the last message, so your stored history stays clean and identical from turn to turn. You use two of your four checkpoints this way, leaving two spare for tools or a large document.

Jake: "So the longer the customer chats, the more it saves?"

Ethan: "Exactly. Without the cache, a long chat gets more expensive every message. With it, you mostly pay for the new bit."

Prompt caching with InvokeModel

With InvokeModel, caching uses each model's native format. For Amazon Nova, the checkpoint is a cachePoint on the content block, much like Converse:

import json
encode = json.JSONEncoder().encode

body = {
    "system": [{"text": "You answer warranty questions. Use only this policy:\n\n" + POLICY,
                "cachePoint": {"type": "default"}}],
    "messages": [{"role": "user", "content": [{"text": "Are keyboards covered?"}]}],
    "inferenceConfig": {"maxTokens": 400, "temperature": 0},
}
resp = brt.invoke_model(modelId="us.amazon.nova-pro-v1:0", body=encode(body))
result = json.loads(resp["body"].read())
print(result["usage"])

For Anthropic's models, InvokeModel uses Anthropic's own format, where the marker is "cache_control": {"type": "ephemeral"} on the content block that ends the cached part (add "ttl": "1h" inside it for the hour-long cache). Prompt caching is enabled by default with InvokeModel; there is no separate switch.

The old parameter error. Early previews of this feature used an extra InvokeModel parameter to turn caching on, and some 2024 tutorials still show it. Current boto3 versions reject it as an unknown parameter, and current Bedrock does not need it. Remove it, keep the checkpoint markers, and update boto3 (pip install -U boto3) if your version predates caching support.

Prompt caching for OpenAI models on Bedrock

OpenAI's models on Bedrock cache differently:

• GPT-5.5 and earlier cache automatically for prefixes of 1,024 tokens or more. No markers, no write fee; just put the static content first.
• GPT-5.6 and later (including GPT-6 Astra and GPT-6.1 Sol) support explicit breakpoints with a 30-minute minimum TTL, up to four cache writes per request, and a 1.25 times write price. Explicit caching for these models works through the Responses API, Chat Completions and InvokeModel, not through Converse.

A Responses API request with one breakpoint after a long developer instruction looks like this:

{
  "model": "global.openai.gpt-6.1-sol",
  "prompt_cache_key": "shop-warranty:v1",
  "prompt_cache_options": {"mode": "explicit"},
  "input": [
    {"type": "message", "role": "developer", "content": [
      {"type": "input_text", "text": "You answer warranty questions... (the full policy)",
       "prompt_cache_breakpoint": {"mode": "explicit"}}
    ]},
    {"type": "message", "role": "user", "content": [
      {"type": "input_text", "text": "Is a swollen battery covered?"}
    ]}
  ]
}

In implicit mode (the default) Bedrock also places an automatic breakpoint on the latest message; explicit mode uses only your breakpoints, which is the better choice for agent loops where you want full control of the four write slots. The response's usage.input_tokens_details shows cached_tokens and cache_write_tokens; when the first is high and the second is zero, the request was a full hit. These requests run on both the bedrock-runtime and bedrock-mantle endpoints; our Mantle guide explains the difference.

Simplified cache management for Anthropic's models

Anthropic's models on Bedrock support both implicit and explicit caching, plus a convenience that removes most of the guesswork about where to put checkpoints. Place a single checkpoint at the end of your static content, and Bedrock automatically looks back over roughly the previous 20 content blocks to find the longest prefix already in the cache. You do not need to predict exactly where earlier cache entries ended.

Two limits come with it. The look-back covers about 20 content blocks, so very long static sections made of many small blocks may extend beyond it; combine them into fewer blocks or add a second checkpoint. And for parts of the prompt that change at different speeds, such as tools that change monthly, a system prompt that changes weekly, and documents that change daily, separate checkpoints after each part still give the best results, up to the limit of four.

Prompt caching in LangChain and Prompt Management

LangChain: with ChatBedrockConverse, add the cache point as a content block in your system or human message:

from langchain_aws import ChatBedrockConverse

llm = ChatBedrockConverse(model="us.amazon.nova-pro-v1:0", region_name="us-east-1")
reply = llm.invoke([
    ("system", [
        {"type": "text", "text": "Answer from this warranty policy:\n\n" + POLICY},
        {"cachePoint": {"type": "default"}},
    ]),
    ("human", "Are batteries covered on refurbished laptops?"),
])
print(reply.usage_metadata.get("input_token_details"))   # shows cache_creation and cache_read

For LangChain agents, where the conversation and tool calls grow with every step, langchain-aws provides BedrockPromptCachingMiddleware, which places cache points for you as the agent runs. Our LangChain with Bedrock guide has the full setup.

Bedrock Prompt Management: when you store prompts in Prompt Management (Bedrock's console for versioned prompt templates), there is an option to enable prompt caching on the prompt, and Bedrock handles the checkpoints for supported models. The console playground has a prompt caching toggle too, with a metrics pop-up showing tokens read from and written to the cache on each reply, which is the quickest way to see caching work before writing any code.

Measuring your savings

You do not need a dashboard product to know whether caching pays. Add a few lines to the code that calls Bedrock, and you get a running total of what you saved:

PRICE_IN, PRICE_WRITE, PRICE_READ = 2.00, 2.50, 0.20   # per million tokens; use your model's rates
totals = {"plain": 0, "write": 0, "read": 0}

def record(usage: dict):
    totals["plain"] += usage["inputTokens"]
    totals["write"] += usage.get("cacheWriteInputTokens", 0)
    totals["read"]  += usage.get("cacheReadInputTokens", 0)

def report():
    all_input = sum(totals.values())
    without = all_input * PRICE_IN / 1e6
    actual = (totals["plain"] * PRICE_IN + totals["write"] * PRICE_WRITE
              + totals["read"] * PRICE_READ) / 1e6
    hit_rate = totals["read"] / all_input if all_input else 0
    print(f"input cost ${actual:.2f} vs ${without:.2f} uncached; {hit_rate:.0%} of input from cache")

Call record(resp["usage"]) after every request and report() at the end of the day. Two numbers tell you everything: the share of input served from the cache (your hit rate) and the cost compared with no caching. If your hit rate suddenly drops, someone almost certainly changed the start of your prompt. Bedrock's model invocation logging, if you turn it on, records the same usage fields for every call, which is handy when you need the history across many services.

Why your cache misses: every reason

The single most common cause is the second row: a "harmless" date or user name at the top of the system prompt. It changes the prefix on every request, and the cache never gets a second use. Move personalization to the end of the prompt.

Designing prompts for caching: a checklist

1. Order by stability. Tools first, then the system prompt, then long reference documents, then the conversation, then the new question.
2. Freeze the static part. Build it from a template with no dates, IDs or names; if you need "today's date," send it in the user message.
3. Put the checkpoint right after the last static block, and make sure everything before it passes the model's minimum.
4. Use separate checkpoints for parts that change at different speeds, up to four, longest TTL first.
5. Keep traffic steady where you can: a cache that is used every few minutes never pays for a rewrite.
6. Measure reads, writes and plain input on every call, and alert if the read share drops, which usually means someone changed the prompt.

For RAG apps, cache the instructions and any document that many questions share, and send the retrieved passages after the checkpoint, since they change with every question. Our knowledge base guide covers the retrieval half of such an app.

Frequently asked questions

A week after the change, Ethan's dashboard showed one cache write each morning around opening time, a few more after lunch, and hundreds of reads in between. The warranty assistant's input bill had dropped by about four fifths, and answers began a little sooner. The only incident came on Friday, when someone added "Today is {date}" to the top of the system prompt "to be helpful" and every request became a cache write. Jake now knows what a prefix is. "The top of the prompt is furniture," Ethan told him. "Nobody moves the furniture."

Revision note. Written October 19, 2026, with the supported-model list as of that date. The cheapest token is the one the model has already read; caching just makes sure it does not read it twice.