# Prompt cache cost optimization > A cache write costs 1.25x input and a read costs 0.1x, so caching pays from the second call inside the window. Volume isn't the variable. URL: https://getculpa.com/prompt-cache-cost-optimization Last reviewed: 2026-08-02 ## Answer 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. ## Common mistakes - Enabling caching on every endpoint because the prefix is shared. Why it hurts: A shared prefix with scattered arrivals pays the write premium and never earns it back. Do instead: 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. Why it hurts: A thousand calls a day can still be one call per window, which is the losing case. Do instead: 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. Why it hurts: It doubles the write premium, so it needs a third call rather than a second to break even. Do instead: Use the five-minute window unless your traffic is genuinely spread, then check against 3. ## Self-check - Group your calls by shared prefix and count how many land in each five-minute window. - If the usual answer is one, caching costs you money on that endpoint. - Compare your cache write count against your total call count on the invoice. - Work out your cached-token share and put it beside the write premium you paid. - 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) 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. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - 2 calls — calls inside one five-minute window at which caching starts to pay [calculated] Source: M = 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 calls — the same break-even once the one-hour cache doubles the write premium [calculated] Source: M = 2.00 + (M - 1) x 0.10 solves to M = 2.11, using the same published multipliers. - $0.315 to $2.50 — modelled monthly cost of twenty calls on one prefix, best arrival pattern to worst [estimated] Source: Both endpoints from the teardown arithmetic at a real Claude Sonnet 5 rate. A range because the arrival patterns are modelled. ## FAQ Q: When does prompt caching actually save money? A: 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. Q: Can caching make my bill go up? A: 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. Q: Does this break-even change by model? A: 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. ## Sources - Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=prompt-cache-cost-optimization&cluster=optimization Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: 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.