AWS: caching agent prompts on Bedrock cut input cost 64%

On 26 October 2026 AWS published a post by Claudio Mazzoni, a senior specialist solutions architect on the Amazon Bedrock go-to-market team, on prompt caching patterns for agents that use OpenAI models on Amazon Bedrock. Its central claim: an agent re-sends its tool list, instructions and entire history on every step, so caching that unchanged prefix is the largest lever on input cost. This is vendor-published guidance, and every number below is AWS's.

What the post reports

For a support-style agent on GPT-6 Astra with an 8,000-token startup prefix and six turns that each add 2,000 tokens, the post says one-time static caching brought input cost to $0.50 a session. Rolling breakpoints, which move the cache boundary forward each turn, cut modelled input cost by 64 percent, from $0.87 to $0.32 per session, using Bedrock on-demand prices.

In a separate six-turn workload, the post says implicit caching, where Bedrock chooses where the reusable prefix ends, gave about 62 percent lower input cost, and explicit rolling breakpoints about 61 percent. In one explicit test, a roughly 4,000-token prefix wrote 4,120 tokens on the first request and read the same 4,120 on later ones. The author writes that these are workload results and tells readers to measure their own agent.

The patterns that decide whether you get the saving

• Keep the prefix identical. The post says caching works only on exactly the same text, so tool lists and instructions must serialise the same way every time, and varying items such as the date or a request ID belong after the cached part.
• Do not move a single breakpoint. In explicit-only mode, moving it can cause repeated writes; keep the previous turn's marker too.
• Do not change the tool list mid-session. Adding, removing or reordering definitions can invalidate the prefix. The post suggests allowed_tools to restrict what is callable and additional_tools to append a new one, which it says works for GPT-6 Astra, GPT-6.1 Sol and GPT-5.6 Luna.
• Warm once, then fan out. Finish one request before launching parallel helper agents, so they read the shared prefix instead of each writing it.
• Share the cache key. A session-specific prompt_cache_key isolates sessions even when prompts match; new sessions reuse a prefix only with the same key, model, AWS account and Region.

What the post leaves out

The savings are modelled on one workload at AWS list prices, with no independent replication. The post says caching improves latency but gives no latency figures. It also states the costs: cache writes are billed at 1.25 times the normal input rate, a cacheable prefix needs at least 1,024 tokens, and entries last at least 30 minutes after the latest write or reuse. A workload with short sessions or constantly changing prefixes pays the write premium without earning the reads back.

The author also warns that with caching, tools and system prompts can be leaked or exploited, and says to include the caching setup in your responsible-AI governance. It does not say how.

How to check it on your own agent

The post points to response usage fields cached_tokens and cache_write_tokens during development. In production on the Bedrock Runtime endpoint it names the CloudWatch metrics CacheReadInputTokenCount and CacheWriteInputTokenCount, and Cost Explorer grouped by usage type, where cache reads, writes and uncached input appear separately. It says the Mantle endpoint has no separate cache counters in CloudWatch yet, so log the usage fields yourself.