Amazon Bedrock prompt caching reads a cached prefix at roughly a 90 percent discount, but a cache write costs more than a normal input token, so a cache that never gets a hit makes your bill worse, not better. The feature has been generally available since April 2025, and the one-hour cache duration that shipped in January 2026 makes it useful for whole sessions and batch jobs. Most teams still leave it off, or turn it on in the wrong place and quietly pay a premium. The discount is real. Whether you capture it depends entirely on where you put the cache breakpoint.

The mental model that trips people up is treating the cache like a free speedup you sprinkle on. It is not free. Every cache checkpoint is a bet that the tokens before it will be resent, unchanged, before the cache expires. Win the bet and you pay a tenth of the read price. Lose it and you paid a write premium for nothing.

How the pricing actually works

Three token classes matter, and they are priced differently:

  • Cache write: the first time Bedrock stores a prefix, those tokens are billed above the normal input rate. On Anthropic models the write is about 1.25x base input for the short cache duration and about 2x for the one-hour duration.
  • Cache read: every later request that matches the stored prefix reads those tokens at roughly 0.1x, the headline 90 percent saving.
  • Uncached input: everything after the last cache checkpoint, billed at the normal rate every time.

The write premium is the whole game. You are prepaying to make future reads cheap. The break-even is simple: you need enough hits on a cached prefix to earn back the extra you paid to write it. One write plus one read can cost more than two plain calls. The savings only compound when the same prefix is read many times.

Where the breakpoint goes

A cache checkpoint says "everything before this point is stable, store it." So put it after the parts of the prompt that do not change between calls, and before the parts that do. In a typical assistant that ordering is:

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

The system prompt and tool definitions are identical on every call, so they belong inside the cached prefix. The new user turn never repeats, so it belongs outside. Retrieved context sits in the middle: cache it if the same documents are reused across a session, leave it uncached if every call retrieves something new. Get this ordering wrong, put the checkpoint before the tool definitions, and you cache almost nothing while still paying to write it.

When a miss costs more than no cache

Cache hits require an exact match on the prefix, byte for byte, and the entry has to still be alive. You lose the bet in three common ways:

  • You mutate the prefix. Injecting a timestamp, a request ID, or a per-user greeting near the top of the system prompt changes the bytes, so every call is a fresh write and never a read. This is the most common own-goal.
  • Traffic is too sparse for the TTL. If requests arrive further apart than the cache lifetime, each one writes and expires before the next arrives. The one-hour duration widened this window a lot, but a low-traffic endpoint can still miss every time.
  • The prefix is below the minimum. Bedrock only caches prefixes past a per-model token floor. A short system prompt may not be cacheable at all, so the checkpoint is ignored and you gain nothing.

In each case you either pay the write premium with no reads to amortise it, or you pay nothing extra but also save nothing while thinking you optimised. Both are worse than a clear-eyed decision to leave caching off for that path.

A quick way to know if it is working

Do not assume the cache is hot. The Converse and InvokeModel responses report cache read and cache write token counts in their usage fields. Log them and watch the ratio. A healthy cached path shows a small, steady stream of writes and a large volume of reads. If writes and reads track each other one to one, your prefix is not stable and you are paying the premium for a cache nobody hits. Fix the prefix or turn the checkpoint off.

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

The takeaway

Prompt caching on Bedrock is not a switch you flip for a free 90 percent. It is a prepaid discount: you pay a write premium up front and earn it back through repeated reads of an unchanged prefix. Put the checkpoint after the stable system prompt and tool definitions, keep anything volatile out of the cached region, and log the read-to-write ratio so you can prove the bet is paying off. Done right it is the cheapest large saving available on Bedrock. Done carelessly it is a line item that makes your bill worse while looking like an optimisation.

Read this next

For the wider cost-optimization playbook across AWS, the cloud field notes live at ercan.cloud, and the hub is at ercanermis.com.