Bedrock cache writes ate 85 percent of one AI bill

Prompt caching is sold as a saving. It can also be the single largest line on an inference invoice, and the failure is quiet, because a cache write succeeds whether or not anything ever reads it back.

One production report puts a number on it, and that number is 85 percent. An open issue filed against the Codex CLI documents 3,656 requests between August 5 and August 8, 2026 that produced 171.94 million cache-write tokens and an estimated $1,182.09 in cache-write cost — roughly 85% of total spend for that period, according to the usage figures in that GitHub thread. A separate local session in the same report shows 76 requests averaging about 88,000 cache-write tokens each, with zero cached input tokens used.

How Bedrock actually bills prompt caching

Prompt caching is a billing feature that stores a stable prefix of a prompt so later requests reuse it instead of paying full input price. Amazon Bedrock is AWS's managed service for calling third-party models through one API.

The two numbers that matter both come from AWS. Cache writes are billed at 1.25 times the uncached input rate, and cache reads are billed at a 90% discount, according to the explicit prompt caching announcement published on July 30, 2026.

Token type	Price, relative to normal input
Uncached input	1.00x
Cache write	1.25x
Cache read	0.10x

Everything about whether caching saves you money follows from those three rows.

The break-even, worked out

Take a prefix of N tokens, written once and read back r times.

• With caching: 1.25N for the write, plus 0.1N for each read. Total: (1.25 + 0.1r) × N.
• Without caching: full price every time. Total: (1 + r) × N.

Caching wins when 1.25 + 0.1r < 1 + r, which solves to r > 0.28.

So you need a little more than one read for every four writes to come out ahead. Put another way, a cache hit rate below roughly 22% of cached-prefix requests is a tax rather than a saving, on the multipliers AWS publishes in its Bedrock pricing documentation. That is a low bar, and most agent workloads clear it comfortably, which is exactly why the failure case gets expensive when it does happen. Nobody audits a feature they have assumed is free money.

The methodology here is simple and reproducible: take your cache-write and cache-read token counts from usage metrics for one week, divide reads by writes, and compare against 0.28.

Why a client can write cache and never read it

The expensive failure is not a bad hit rate. It is a hit rate of zero, with writes on every single request.

Explicit caching on Bedrock requires the client to send specific fields, and AWS documents three of them. There is prompt_cache_options, set to {"mode": "explicit"}, a prompt_cache_breakpoint marking where the reusable prefix ends, and a prompt_cache_key that routes repeat requests to the same cached entry.

The reported Codex CLI issue is precisely this shape. Its native Bedrock provider does not include prompt_cache_options or prompt_cache_breakpoint in the request types it builds, so the model never learns where the reusable prefix stops, even though the CLI does emit a session-scoped cache key. Every request pays the 1.25x write, and none of them collects the 0.1x read.

For example, an agent with a 90,000-token system prompt and tool schema in front of a short user turn will re-write that entire prefix on every call. At the 1.25x write multiplier documented in AWS's caching guidance, that is less a caching bug than a 25% surcharge applied to the most expensive part of every request, on AWS's published multipliers.

How to check your own bill this week

Three checks, in the order that finds the problem fastest.

1. Pull the token split. Get cache-write, cache-read and uncached input token counts for the last seven days. If cache-read is zero while cache-write is large, stop here — you have found it.
2. Inspect one real request body. Log the JSON your client actually sends, not what the SDK docs say it sends. Look for the breakpoint and options fields by name.
3. Divide reads by writes. Compare against the 0.28 break-even. Between zero and 0.28, caching is costing you money and should be switched off until the client is fixed.

Wrapper libraries and agent frameworks are the usual culprits, which is the same lesson the dev.to write-up of Bedrock's hidden caching cost reaches from a different direction. Your application code can be perfectly correct while the layer beneath it drops the fields that make caching work.

Should you turn prompt caching on, off, or fix the client?

Fix the client if the workload has a stable prefix. Turn caching off if it does not.

• Stable prefix, many turns — such as an agent with a fixed system prompt and tool definitions across a long session. Caching pays. Verify the breakpoint fields are actually being sent.
• Stable prefix, one-shot calls — a classifier that runs once per document, for example. Reads never happen, so caching is a pure 25% surcharge. Leave it off.
• Unstable prefix — if the first tokens of your prompt change per request, there is nothing to cache. Restructure the prompt before enabling anything.

A note on prefix design: anything that varies, such as a timestamp or a user ID injected at the top of the system prompt, invalidates the cached prefix for every request. Agent memory that does not wreck your prompt cache is a design constraint, not an optimisation to add later.

The wider point about inference pricing

Caching, routing and batching are all sold as discounts, and all three depend on the client sending the right request shape. The headline rate per million tokens is the number everyone compares, and it is rarely the number that decides the bill. The cheapest AI API is not the cheapest to run, and Bedrock caching is a clean example: the same model, the same prompts, and a 25% swing in either direction depending on three fields in the request body.

For teams in the United States and Europe billing this to a cloud account in dollars, the audit above takes an afternoon and is worth doing before the next invoice, not after it.