Field Notes: Where a real production hit ratio sits against the prompt caching break-even point

The prompt caching break-even formula already exists in a few places online, worked against Anthropic’s first-party API pricing: one example, another. Neither of those checks the formula against a real measured production hit ratio rather than an illustrative one. This post does that: the real 99.8% hit ratio this workload measured on Bedrock checked against the floor the published first-party pricing produces.

Prompt caching, a Bedrock feature that lets you reuse a previously-processed prompt instead of paying full price to process it again, bills every call one of two ways: a cache write, which costs more than a normal call, or a cache read, which costs much less. The two-kwarg fix and the per-model gotchas are in the earlier post. This one is the arithmetic the “turn it on, it saves money” advice skips: the write costs more, so caching only pays off once enough of your calls are reads.

In short

• Anthropic’s first-party cache write premium for Sonnet 4.6 is 1.25x the normal input price, checked live today. Bedrock bills Claude models separately from the first-party API, so check the Bedrock console for your own exact rate before relying on this number for a Bedrock bill.
• Below a hit ratio of about 21.7% on Sonnet 4.6’s published first-party multipliers, caching costs more than not caching at all. Above it, every extra read is pure savings. The formula holds regardless of which multipliers your actual bill uses, only the floor’s exact percentage shifts.
• The real production hit ratio this workload measured on Bedrock, 99.8%, sits nowhere near that floor. The risk zone is a specific kind of workload: infrequent calls against a prompt that keeps missing the 5-minute cache window (the gap after which a repeat call stops being cheap), not the typical agentic burst pattern.

Prompt caching is a toll pass, not a discount

Think of it like a toll road pass. You pay more for the pass than a single toll costs, on purpose, because you plan to use the road again before the pass expires. If you only cross once, the pass cost you more than just paying the toll would have. Prompt caching is the same trade: a cache write costs more than a normal call, and you only come out ahead if enough reads land before the cache expires.

Bedrock’s cache has a TTL, short for time to live: the window after a write during which a matching call reads from the cache instead of paying full price again. For most Bedrock models, including Sonnet 4.6, that window is five minutes from the last write or read. Miss the window and the next call pays a fresh write, same as a new toll pass bought because the old one lapsed.

The real, verified numbers, and the one gap in them

Checked today against Anthropic’s published first-party API pricing, not from memory and not carried over from an earlier draft: Sonnet 4.6’s base input price is $3 per million tokens. A 5-minute cache write costs $3.75 per million tokens, exactly 1.25x the base price. A cache read costs $0.30 per million tokens, exactly 0.10x the base price. Same multipliers the earlier post on this workload cited, still current.

Those are Anthropic’s first-party API rates. Anthropic’s own pricing page states plainly that Claude on Amazon Bedrock is partner-operated with separate pricing, and I could not pull Bedrock’s own exact cache multiplier for Sonnet 4.6 today: the Bedrock pricing page’s rate tables are JavaScript-rendered and didn’t come through a fetch, and the AWS Price List API’s Bedrock model catalogue in the tool I tried hasn’t been updated past Claude 3 Sonnet. If your workload runs on Bedrock, check the Bedrock console for your account’s exact rate before trusting the first-party number above on your own bill. The formula below does not depend on which number is right, only the floor’s exact percentage does.

Every model publishes its own write and read multiplier, and they are not all the same. Plug in your own model’s published numbers rather than assuming Sonnet 4.6’s apply elsewhere.

Where the floor actually is

Over N calls against the same cacheable prefix, with hit ratio h (the fraction that land as reads), the average price per call relative to the uncached price is:

cost ratio = (1 - h) * w + h * r

where w is the write multiplier (1.25 for Sonnet 4.6) and r is the read multiplier (0.10). Caching breaks even, cost ratio equal to 1, the price of a call with no caching at all, when:

h* = (w - 1) / (w - r)

For Sonnet 4.6: (1.25 - 1) / (1.25 - 0.10) = 0.25 / 1.15 ≈ 21.7%.

Below a 21.7% hit ratio, enabling caching on Sonnet 4.6 costs more than leaving it off. Above it, every additional read is savings on top of savings, because the read price is so far below the uncached price that it pulls the average down fast once writes stop dominating.

The 21.7% floor is lower than most teams would guess, which is the actual finding here: it takes very little genuine reuse to come out ahead, not the near-total reuse the “99.9% hit ratio” headlines imply is the bar.

The decision this reduces to, before flipping caching on for a new workload:

flowchart TD
    A["Estimate the real hit ratio:<br/>will repeat calls land inside the TTL?"] --> B{"Hit ratio ><br/>break-even floor h*?"}
    B -- "No, mostly fresh writes" --> C["Caching costs MORE than no caching.<br/>Leave it off, or fix the call pattern first."]
    B -- "Yes, genuine reuse" --> D["Caching saves money.<br/>Turn it on, verify with the usage block."]

The specific workload that can lose money

The floor is forgiving, but it is a real floor, and it is possible to be below it. The workload that lands there is not the bursty, many-calls-per-turn agentic pattern the earlier post measured, where every call inside a user turn lands well within the 5-minute window. It is the opposite: a prompt that gets called once, then not called again until well after the TTL has lapsed, every time. Every call in that pattern is a fresh write, and the hit ratio sits at 0%, 25% more expensive than if caching had never been turned on.

A scheduled job that runs the same system prompt once an hour is the clean example: five minutes of TTL cannot bridge a sixty-minute gap, and every invocation pays the 1.25x write premium for nothing. A chatbot with long, unpredictable gaps between messages from the same user can land in the same zone if traffic is thin enough. The fix in both cases is not to turn caching off, it is to check the actual call pattern against the TTL before assuming caching is free money to enable.

What I now do

Before enabling caching on a new Bedrock workload, two checks, in order:

1. Pull the model’s published write and read multiplier and compute the break-even hit ratio with the formula above, rather than assume it is always worth it.
2. Estimate the real call pattern’s gap between repeated calls against the same prefix, against the 5-minute TTL. If the typical gap is well under five minutes, caching is close to free money. If it regularly exceeds five minutes, measure the real hit ratio with the per-call usage block technique from the earlier post before trusting the default advice.

The two-kwarg fix is still right for the overwhelming majority of workloads. This is the one case where turning it on without checking first can make the bill worse, not better.

What this doesn’t tell you

• This is worked economics, not a second measured production case. The 99.8% hit ratio cited here is the same real number the earlier post measured on this workload; this post derives where the break-even point sits relative to it, it does not re-run a new experiment against a workload that actually falls below the floor.
• The formula assumes one cacheable prefix at a steady multiplier. A workload caching several different prefixes at different reuse rates needs the formula run per prefix, not blended across all of them.
• TTL extensions change the math. Some Bedrock models support a longer, paid TTL option alongside the default 5-minute one; that changes both the write premium and the achievable hit ratio, and is out of scope here.

Sources

• Anthropic first-party API pricing (verified 2026-11-10: Sonnet 4.6 base $3/MTok, 5-minute cache write $3.75/MTok, cache read $0.30/MTok; Bedrock’s own rate for the same model is billed separately and was not retrievable at time of writing, see the caveat above)
• Amazon Bedrock prompt caching documentation (TTL behaviour, explicit vs implicit caching, per-model minimums)
• Field Notes: Turning prompt caching on for a production Bedrock workload (the real 99.8%/99.9% measured hit ratios this post works the break-even math against)

If you are running production AI on AWS and want to compare notes, or get a second pair of eyes on a workload, happy to chat. Find me on LinkedIn or via rajmurugan.com.