Production cost review
Prompt caching cost savings: a break-even guide
A cached prefix costs more than a normal read on its first call. Find the reuse count where the discount on later reads repays that premium.
01 / Two prices, one prefix
Providers bill the first cached read above the base rate.
With provider-side prompt caching, you pay a write price once for a stable prefix, such as a system prompt, tool schema, or reference document. Each later call that reuses it while the provider keeps it cached pays a discounted read price. On the rate cards compared in the September 2026 pricing snapshot, the write price sits above the normal input price and the read price is a small fraction of it. You save money once enough reads recover that premium.
Full-response caching is a separate mechanism: it skips the model call for a repeated or near-duplicate request. A workload can use either or both. The production cost-optimization checklist covers them together; this guide isolates the prompt-caching arithmetic.
02 / Formula
Solve for the minimum number of reuses.
Let p be the normal input price, w the cache write price, r the cache read price, and nthe number of calls that reuse the same prefix within the cache's active window. You come out ahead once the write plus the remaining reads cost less than paying the normal price n times.
Round the result up. Below that count, caching this prefix costs more than not caching it.
03 / Illustrative worked example
Two calls can break even.
On September 30, 2026, Anthropic's pricing page listed Claude Opus 5.5 at $4 per million input tokens, $5 per million for a 5-minute cache write, and $0.20 per million for a cache read. Applying the formula:
4.8 ÷ 3.8 is about 1.26, rounded up to 2. At one call, caching costs $5.00 per million tokens against $4.00 uncached, a loss. At two calls, caching costs $5.20 against $8.00 uncached, a win. These are Opus 5.5 rates on that date; check the current rate card before applying them to another model or date.
04 / What breaks the savings
A favorable formula still needs the right traffic shape.
The prefix changes between calls
A timestamp, a user ID, or a reordered tool list inside the cached segment invalidates the cache on each call. Put anything that varies after the stable prefix.
Traffic is too sparse for the TTL
A cache entry expires after the provider's TTL, 5 minutes on Anthropic's standard tier. If the same prefix does not repeat within that window, you pay the write price on each call and never earn a read.
Storage or lookup fees are missing from the model
A per-token price comparison can miss separate storage, lookup, or higher-tier TTL charges. Get the complete rate card before computing break-even.
05 / Before implementing
Confirm the traffic pattern, then confirm the rate card.
- Isolate the stable prefix.Move anything request-specific after it, and confirm the provider caches by prefix.
- Measure reuse within the TTL window.Count calls that share the exact prefix within one cache lifetime. A daily total overstates reuse.
- Get the complete rate card.Write price, read price, any TTL tiers, and storage or lookup charges, from the provider's current documentation.
- Apply the break-even formula.Compare the minimum reuse count against the measured reuse rate before implementing.
- Recheck after volume or traffic-shape changes.A workload that grows or changes its request pattern can cross the break-even point in either direction.
Enter prompt-cache coverage and response-cache hit rate together.
The inference planner projects both cache types alongside routing, retries, and latency.
06 / Common questions
Apply the break-even to common cases.
Does a higher-TTL cache tier change the break-even count?
Yes. Longer TTL tiers can carry a higher write price, so recompute the formula with that tier's write price. A longer TTL can still cost less overall if it captures reuse a shorter TTL would miss.
Does prompt caching change output quality?
No. The model receives the same input with or without the cache. Caching changes what you pay for the prefix, and it can shorten response time.
How is this different from the inference planner's cache field?
The planner applies one discounted price to cached input tokens to project monthly cost. This guide explains the write-versus-read mechanics behind that discount, including the reuse count needed to earn it.
Is caching worth it below the break-even count?
Not on cost alone. It can still be worth it if the provider's cache read path also reduces latency in a way that matters for the workload, separate from the token price.
07 / Limitations
Rate cards and reuse patterns both move.
Provider prices change. The worked example uses Opus 5.5 rates from September 30, 2026 to show the method; check the provider's current rate card before applying the formula to a production decision.
Your reuse rate comes from your traffic and moves with it. Verify a production change against a normalized baseline over a stated observation window, and recheck the break-even count after a change to request volume, prefix content, or provider pricing.