Guides / prompt cache cost optimization

Prompt cache cost optimization

Caching pays from the second call that lands inside the cache window, because a five-minute write bills at 1.25 times the input rate while a read bills at a tenth. A one-hour write needs a third call. Culpa, a local-first LLM cost, margin, and forecast ledger, measures how many of your calls arrive inside a window rather than how many arrive in a day.

Why this happens

Caching gets sold on volume and decided by timing. The write premium is paid once and recovered only by reads that land before the entry expires, so the question is never how many calls share a prefix. It's how many of them arrive within five minutes of each other. A busy endpoint with a thousand daily calls spread evenly never gets two into one window, pays the write premium a thousand times and recovers none of it. A quiet endpoint with bursts of ten saves most of its input cost. Traffic shape decides this, and traffic shape is the one thing a provider dashboard never shows you.

What this usually looks like

  • Caching was enabled everywhere and the bill went up rather than down.
  • Your cache hit rate is low and your call volume is high, which reads as a contradiction.
  • Nobody can say how many of your calls arrive within five minutes of a matching one.
  • Cache writes appear on the invoice in numbers close to your total call count.

Free, no card, no account

Run the free Cost Leak Scan

It shows your most expensive conversation before you install anything.

Run a free scan

Mistakes that cost the most

MistakeWhy it hurtsDo instead
Enabling caching on every endpoint because the prefix is shared.A shared prefix with scattered arrivals pays the write premium and never earns it back.Enable it where two calls land inside one window, and measure that before switching it on.
Reading daily call volume as evidence that caching will pay.A thousand calls a day can still be one call per window, which is the losing case.Count calls per five-minute window, not per day. That's the number the break-even uses.
Reaching for the one-hour cache to be safe.It doubles the write premium, so it needs a third call rather than a second to break even.Use the five-minute window unless your traffic is genuinely spread, then check against 3.

Run this check tonight

  1. Group your calls by shared prefix and count how many land in each five-minute window.
  2. If the usual answer is one, caching costs you money on that endpoint.
  3. Compare your cache write count against your total call count on the invoice.
  4. Work out your cached-token share and put it beside the write premium you paid.
  5. Switch the endpoints that fail the test back off and re-measure a week later.

The same twenty calls, saving 84% or costing 25% more

Illustrative example

A 50,000-token shared prefix on Claude Sonnet 5 at a real rate of $2.00 per million input, effective 2026-07-02. Anthropic bills cache reads at 0.10 times input, five-minute writes at 1.25 times and one-hour writes at 2.00 times, constant across all 12 Claude rows in the price book. Arrival patterns are modelled.

Uncached, per call: 50,000 x $2.00 per million = $0.10
Five-minute write: 50,000 x $2.50 per million = $0.125
Cached read: 50,000 x $0.20 per million = $0.01
Break-even: M calls uncached = 1.25 + (M - 1) x 0.10, so M = 1.28 and the second call pays
Twenty calls inside one window: $0.125 + (19 x $0.01) = $0.315 against $2.00 uncached, an 84% saving
The same twenty calls one per hour: 20 writes x $0.125 = $2.50 against $2.00 uncached, 25% worse
One-hour cache instead: 2.00 + (M - 1) x 0.10 = M, so M = 2.11 and the third call pays

Twenty calls, one prefix, one model and one rate card, and the answer swings from an 84% saving to a 25% surcharge on arrival times alone. Nobody bought more or less traffic between those two lines.

Every number, with its confidence and source

FigureWhat it meansConfidenceSource
2 callscalls inside one five-minute window at which caching starts to paycalculatedM = 1.25 + (M - 1) x 0.10 solves to M = 1.28, using Anthropic's published write and read multipliers from the price book, effective 2026-07-02 and re-verified 2026-08-02.
3 callsthe same break-even once the one-hour cache doubles the write premiumcalculatedM = 2.00 + (M - 1) x 0.10 solves to M = 2.11, using the same published multipliers.
$0.315 to $2.50modelled monthly cost of twenty calls on one prefix, best arrival pattern to worstestimatedBoth endpoints from the teardown arithmetic at a real Claude Sonnet 5 rate. A range because the arrival patterns are modelled.

What a generic answer can’t know

A provider bills your writes and your reads and never tells you which calls could have shared a window, because that needs your own call timestamps grouped by prefix. The rate card is public and the traffic shape is yours alone. Culpa measures it on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.

Questions founders ask next

When does prompt caching actually save money?

From the second call that lands inside the cache window. A five-minute write costs 1.25 times the input rate and a read costs a tenth, so one write plus one read beats two uncached calls. With the one-hour window the write costs twice input, so it takes three calls.

Can caching make my bill go up?

Yes, and it's the common failure. If your calls rarely land two-in-a-window you pay the write premium on almost every call and collect almost no reads. Twenty scattered calls in the teardown cost 25% more than not caching at all.

Does this break-even change by model?

No. Anthropic's multipliers are the same on every Claude row in the price book, checked 2026-08-02: reads at 0.10 times input, five-minute writes at 1.25, one-hour writes at 2.00. The break-even is a ratio, so it holds whatever the model costs.

On your infrastructure

Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.


How Culpa works

Find the culprit. Not just the total.

Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.

Your prompts stay local.

Culpa runs on your own infrastructure. What you send to a model reaches us at no point.

Every dollar has a name.

Follow any charge to the conversation, the user, the feature and the customer behind it.

See the bill before it lands.

Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.

Three steps to your first answer.

1

Change one base URL.

Or drop in the Python or TypeScript library.

2

Find your most expensive conversation.

In the first session, not the first week.

3

Cost your next feature before you ship it.

Base URLhttp://localhost:4545/v1Your traffic keeps flowing if Culpa ever stops.

Why the bill went up

Example dashboard

Calls traced

418,209

across 3 projects

Spend this week

$378.41

+ $182 vs last week

Failed calls

312

74% retried, and you paid for all of them

+ $182 this week traced to one culprit

Spend over 14 days

$0$20$40$60$8024262830020406
user_384report_generatorconv_91fprompt_v1894,220 tokens3 retries$6.81

Most expensive users

user_384$38.42
user_119$21.07
user_562$14.90
user_204$8.30
user_871$5.10

Next week forecast

Best$180
Median$240
p90$310
p99$395

Graded against reality. Accuracy shown as results land.

Free, no card, no account

Run the free Cost Leak Scan

It shows your most expensive conversation before you install anything.

Run a free scan

Keep reading


Sources: Anthropic pricing. Last reviewed 2026-08-02. Plain text version.