Prompt caching economics: write premiums, read discounts and break-even reuse

Prompt caching is the largest cost lever most AI products have after model choice. It is also the easiest to get wrong, because the providers price it differently and because cache hits depend on how your prompts are assembled and how your customers behave. This guide covers the pricing mechanics, the break-even math and the prompt layout rules that make caching pay.

Anthropic: pay to write, save on every read

Anthropic caching is explicit: you mark cache breakpoints in the prompt. Writing a prefix to the default five-minute cache costs 1.25x the base input price, and reading it costs 0.10x. On Claude Sonnet 4.5 that is $3.75 to write and $0.30 to read per 1M tokens, against $3.00 uncached. A one-hour cache is also available at a higher write premium of 2x input.

The break-even is quick. In units of the uncached prefix cost, n calls without caching cost n. With caching they cost 1.25 for the first call plus 0.10 for each later call. One call: 1.25 vs 1.00, a loss. Two calls: 1.35 vs 2.00. Ten calls: 2.15 vs 10.00. With the one-hour cache, two calls cost 2.10 vs 2.00, so you need a third call inside the hour to come out ahead.

OpenAI: automatic, no write premium

OpenAI caches long prompt prefixes automatically once a prompt passes a minimum length, with no write premium and no code change. The discount on cached input depends on the model. From the index: GPT-4o cached input is $1.25 against $2.50, a 50% discount, while GPT-5 cached input is $0.13 against $1.25, a 90% discount.

Because there is no write premium, caching on OpenAI can only lower your bill. The economic question is not whether to cache but whether your prompts are laid out so the cache actually hits, and whether you are measuring the hit rate per tenant.

Gemini: implicit and explicit caches

Gemini 2.5 models apply implicit caching to repeated prefixes, and also support explicit context caches that you create, reference by name and keep alive for a chosen time. Explicit caches bill a storage charge for the time they exist in addition to the discounted read price. That makes them worthwhile for large shared contexts read many times an hour, such as a product manual behind a support assistant, and wasteful for contexts read once or twice.

What one tenant is worth

Take one busy tenant with a 30k-token stable prefix and 4,000 calls a day on Claude Sonnet 4.5. Without caching, the prefix alone costs $10,800 a month. If 90% of calls read from cache and 10% write it, the prefix costs $2,322, a saving of $8,478 a month for one tenant.

The same prompt for a tenant with a few calls an hour may never hit a five-minute cache, and on Anthropic would pay the write premium on most calls. Measure hit rate per tenant before you decide caching is working.

Prompt layout rules

• Put stable content first: system instructions, tool definitions, then long reference documents. Put the user's message and anything that changes per call last.
• Remove volatile values from the prefix. A timestamp or request ID in the system prompt breaks every cache hit.
• Keep tool definitions in a fixed order. Reordering them changes the prefix.
• Version your prompts and record the version on each request, so a deploy that breaks the prefix shows up as a hit-rate drop on that version.
• For multi-tenant prompts, place shared content before tenant-specific content, so all tenants share the first cache segment.

Accounting for cache in margin

Record cache writes and cache reads as separate token classes on every request and price each at its own rate. If you bill customers for usage, decide whether to pass cache savings through. Most teams bill at a fixed rate per unit and keep the saving as margin, which keeps invoices stable when hit rates move. Either way, internal margin reporting must use the real cached cost, or tenants with warm caches will look less profitable than they are.