Prompt Caching for Agents on Amazon Bedrock: Patterns That Cut Input Cost About 62%

Every step an AI agent takes, it re-reads everything that came before. A new AWS Machine Learning blog post, Groundhog Day for AI agents, published October 26, 2026, shows how prompt caching on Amazon Bedrock stops you paying full price for that repetition when you run OpenAI models. In one six-turn test with GPT-6 Astra, AWS reports about 62 percent lower input cost than no caching.

This guide condenses the patterns, explains the traps, and tells you how to check the numbers on your own workload. All figures below are AWS's, from one test setup.

TL;DR

Why agents are expensive: the Groundhog Day problem

A model keeps no memory between requests. Each call must include the tool list, the developer instructions, the full history of tool calls and results, and the newest message. AWS describes this as a loop in which, by turn 20 of a coding session, the model re-reads turns 1 to 19 and you pay for every one of those tokens again.

Prompt caching saves the work of prefill, the pass in which the model processes every input token and builds its working state. When a later request begins with identical text, the service loads the saved state and only processes what is new. This is the same idea behind the cost-cutting tips in our Claude Code token-efficiency guide and the Claude platform notes on caching and effort, applied to OpenAI models served through Amazon Bedrock. For the pricing background, see AI token pricing, explained.

Pattern 1: cache the static part first

Mark the end of your stable prefix, tools plus instructions, with an explicit breakpoint and give the request a prompt_cache_key. AWS's example uses a key such as support-agent:v7:gpt-6-astra, sets mode explicit, a 30-minute TTL, and places prompt_cache_breakpoint on the developer instructions block. In its test, a roughly 4,000-token tools-and-instructions prefix wrote 4,120 tokens on the first request and read 4,120 tokens on later requests.

Three rules from the post:

1. Identical text. Serialize instructions and tool lists the same way every time. MCP servers and other tool delivery paths must produce a consistent order.
2. Put variable content after the cached part. Dates, user names and request IDs go after the instructions.
3. Setting store=False does not disable caching. It only keeps conversation history in your application.

Pattern 2: let implicit mode follow the conversation

For a growing conversation, implicit mode lets Bedrock decide the endpoint, which by default falls after the latest eligible message. A caveat: if the next request is a different task, it won't match a prefix that ended at the old task, and the implicit write doesn't necessarily create a separate entry for just the tools and instructions. That is why AWS recommends combining modes: an explicit marker after the shared instructions plus implicit mode for the rest.

Pattern 3: rolling breakpoints for tool loops

In an agent loop, each turn adds a tool result. In implicit mode Bedrock can reuse the unchanged prefix and cache through the last tool result. In explicit-only mode, you add a new breakpoint on the newest result each turn and keep the earlier ones, so each turn reads everything before it and writes only its own result. Moving a single breakpoint instead of keeping the old one can prevent reuse and cause repeated writes.

Pattern 4: changing tools without wrecking the cache

Adding, removing or reordering tool definitions can invalidate the cached prefix. AWS gives three options:

• Known tools in different steps: send the same sorted tool list and restrict with allowed_tools via tool_choice. The restriction does not change the cached catalog.
• A new tool mid-session: append an additional_tools item to history, leave the original tool list unchanged. In AWS's example, the old prefix was read (2,048 tokens) and only the new part written (256).
• Different agent roles: choose a stable tool profile such as support or billing at session start; each profile gets its own cached prefix.

Pattern 5: subagents and side calls

For helper agents, AWS says to warm the shared prefix once, wait for it to finish, then fan out. The warm-up can be an ordinary request with a tiny output cap, and you should check that cache activity occurred before launching helpers. Each helper then adds only its own task. For a summarizer or judge, copy the parent's full history and append a new instruction; the cached history is reused, though the appended instruction itself isn't cached unless you mark it.

Pattern 6: keys, pauses and new sessions

A session-specific prompt_cache_key isolates sessions even when prompts match. Keep the key stable for requests meant to share a prefix. AWS suggests deriving it from app name, model, prompt version and a hash of the instructions so a prompt change automatically starts a new cache. After a pause longer than the TTL, the cache may expire; weigh a cheap warm-up request against rebuilding.

What the numbers do and don't say

AWS reports that GPT-6 Astra tied for the best implicit result in its six-turn workload at about 62 percent lower input cost than no caching, and that explicit rolling breakpoints saved about 61 percent. AWS also lists a pitfall: a single static breakpoint in explicit-only mode caches tools and instructions but reprocesses the growing history every turn, so it saves less than rolling breakpoints. The post shows a chart of input cost for each setup relative to no caching; we did not reproduce its exact values for that case, so check the original chart before quoting it.

Treat these as workload results. Savings scale with how much of each request is a repeated prefix. A short, one-shot call gets little; a long agent session with large tool definitions gets a lot. Output tokens are not reduced by caching at all, so the total bill falls by less than the input cost does. AWS itself says to measure your own agent's savings.

For related cost data, our post on OpenAI's cached-prompt claims shows how cache lifetimes are marketed, and the GPT-6 Astra quota analysis covers how reasoning effort changes per-task cost.

A quick decision guide

If you are not sure which pattern to start with, this is our reading of the AWS post, not a rule it states.

The common thread is that the prefix is a contract: whatever comes first in the request must be byte-for-byte stable, and anything that varies must come last. Teams that treat prompt construction like an API surface, versioned and tested, tend to keep hit rates high. Teams that let a templating change slip a timestamp to the top of the system prompt find out when the bill arrives.

Security note

AWS includes a warning worth repeating: when you use caching with AI agents, tools and system prompts can be leaked or exploited, so include your caching implementation in your responsible AI governance. Practical steps are to keep per-tenant data out of shared keys, never place secrets in the cached prefix, and keep tenants on separate keys. For how agent platforms can fail in other ways, see our write-up of the AgentCorruption hijack of Bedrock AgentCore agents. If you run agents with real credentials, AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.

How to measure your own savings

1. Log cached_tokens and cache_write_tokens from each response's usage details.
2. Replay a representative session with caching off, implicit, and combined.
3. Compare input cost per completed task, not per request.
4. Check hit rates after every prompt or tool change, since a one-character difference breaks reuse.
5. Alert when the hit rate drops, which usually means someone changed the serialization.

Related reading on explainx.ai:

• Claude Code token efficiency and prompt cache sessions
• Claude platform cost, performance and prompt caching
• AI token pricing, explained
• OpenAI 12-hour prompt caching claim
• GPT-6 Astra xhigh cheaper than medium quota claim
• Microsoft token wars: cutting cost per answer with caching

Based on the AWS Machine Learning blog post of October 26, 2026; model availability and caching rules vary by Region and can change.