Prompt Cache Break-Even: When Caching Actually Saves Money

Publication note: the underlying price rows and this article were separately approved by the site owner on 2026-08-22. Sources and prices were checked on 2026-08-22. Every dollar result below is simulated, not a customer bill or production benchmark.

Prompt caching sounds simple: send a long prompt once, reuse it, and pay less. The accounting is not simple. Some providers charge more when they write a prefix into cache, one provider charges for how long an explicit cache exists, and another manages caching automatically without guaranteeing that a request will hit. A statement such as “cached input costs 90% less” is therefore incomplete. It describes one billing line, not the conditions required to earn the saving.

This experiment answers a narrower and more useful question: how many successful reuses are required before caching a stable prompt prefix costs less than sending that prefix as ordinary input? It uses one million reusable prefix tokens so the official per-million-token rates remain visible in the arithmetic. The break-even count does not change with a smaller eligible prefix when every relevant rate scales linearly, although the dollar saving does.

The source data is available as cache-break-even.json and the six deterministic cases are available as cache-break-even.csv. The calculations are reproduced by a build-time verification script. Output tokens and the changing suffix of each prompt are excluded because both alternatives pay for them. This is a comparison of the reusable prefix only, not total request cost, latency, response quality, or model capability.

The three billing shapes must not be merged

The providers in this experiment fit three different formulas.

For a cache with a priced write, let B be the ordinary input rate, W the cache-write rate, R the cache-read rate, and K the total number of times the same eligible prefix is used. Sending it normally costs K × B. Writing once and then reading the cache costs W + (K − 1) × R. Caching is profitable only when the second expression is strictly lower. OpenAI GPT-5.6 and Claude prompt caching fit this form.

For explicit caching with storage charges, let S be the hourly storage rate, T the TTL in hours, and N the number of subsequent reads. Repeating the content costs N × B; keeping and reading the cache costs S × T + N × R. Gemini explicit caching fits this experiment’s storage-priced form. A longer TTL creates a real carrying cost even if no request uses the cache.

For a best-effort automatic cache, a promised reuse count is not available. Let Q be requests and H the observed hit rate. Expected prefix cost is Q × [H × R + (1 − H) × B]. DeepSeek fits this form. Any realized hit can reduce the token charge, but a theoretical hit is not the same as a billed hit.

These shapes are deliberately shown as not comparable where the provider does not expose an equivalent field. A blank cache-write fee must not be treated as zero unless the provider’s billing rules support that interpretation. Likewise, a provider-managed lifetime must not be converted into a customer-selected TTL.

OpenAI GPT-5.6 Sol: one successful read repays the write premium

The current OpenAI prompt-caching guide says GPT-5.6 and later models can use explicit breakpoints while implicit caching remains available. An eligible prefix must contain at least 1,024 rendered tokens. Cache reads are billed at 0.1 times ordinary input, writes at 1.25 times ordinary input, and the supported TTL is 30 minutes. The response reports cached_tokens and cache_write_tokens, which are the fields an operator should monitor rather than assuming a hit.

For GPT-5.6 Sol, the approved catalog used here records $5 ordinary input, $6.25 cache write, and $0.50 cache read per million tokens. Two normal uses cost 2 × $5 = $10. One write followed by one successful read costs $6.25 + $0.50 = $6.75. The first successful reuse therefore produces a simulated saving of $3.25 per million reusable prefix tokens.

That arithmetic is only valid when the prefix is identical through the breakpoint, the requests share the intended cache key, and the read occurs while the entry is reusable. Content that changes before the breakpoint—timestamps, request IDs, incoming user text, or changing tool definitions—can cause repeated writes or misses. The operational test is simple: if cache_write_tokens remains high while cached_tokens remains low, the economical break-even exists on paper but the prompt design is not reaching it.

Official references: OpenAI prompt caching and OpenAI API pricing.

Claude Sonnet 5: the selected lifetime changes the break-even point

Anthropic provides 5-minute and 1-hour cache writes. Its current documentation prices a 5-minute write at 1.25 times base input, a 1-hour write at 2 times base input, and a cache read at 0.1 times base input. Claude Sonnet 5 requires at least 1,024 cacheable prefix tokens. The default 5-minute lifetime refreshes when cached content is used; the documentation also warns that response-generation time counts against that lifetime.

At the approved Claude Sonnet 5 rates, base input is $2, a 5-minute write is $2.50, a 1-hour write is $4, and a cache read is $0.20 per million tokens.

For the 5-minute cache, two normal uses cost $4. A write and one read cost $2.50 + $0.20 = $2.70, so the first hit pays back the premium and saves a simulated $1.30.

For the 1-hour cache, two normal uses cost $4, while a write and one read cost $4 + $0.20 = $4.20; that is still $0.20 more expensive. At three total uses, normal input costs $6 and the cache costs $4 + 2 × $0.20 = $4.40. The second hit is the first profitable point, saving a simulated $1.60.

This is a useful product decision, not merely a price-table detail. A workload that reliably repeats within five minutes should not automatically pay for a one-hour write. A workload that repeats after six or twenty minutes cannot use the shorter lifetime for that later request. Before selecting the lifetime, measure the distribution of time between requests that share the same prefix. A high reuse count outside the TTL does not produce cache reads.

Claude also checks prefixes and exposes cache creation and cache read usage. A prefix below the model minimum is processed without caching. Changing content before a breakpoint can lead to fresh writes without reuse. Therefore, the rate formula and usage fields must be reviewed together.

Official references: Anthropic prompt caching and Claude API pricing.

Gemini 3.7 Flash: TTL storage can consume the read discount

Google documents both implicit and explicit context caching, but they are not interchangeable. Implicit caching is enabled by default for current Gemini models and can pass on savings when a request hits, yet the documentation does not guarantee a saving. Explicit caching is available through the Generate Content API and allows the developer to choose a TTL; the default is one hour. Google bills cached tokens at a reduced rate and also bills storage according to cached token quantity and duration.

Gemini 3.7 Flash requires at least 4,096 input tokens for caching. Under the promotional rate recorded through 2026-12-31, this experiment uses $0.75 ordinary input, $0.075 cached input, and $0.50 cache storage per million token-hours. The scheduled 2027 rates are outside this experiment and must be recalculated before reuse after that date.

The reviewed Google documentation enumerates cached-token reads and storage duration, but does not enumerate a separate explicit cache-write token rate. The simulated formula therefore compares the cost of subsequent repeated inputs with storage plus subsequent cached reads. That is a disclosed billing assumption, not a claim about every line that may appear on an invoice. Teams should verify a small real cache against their billing export before forecasting production spend.

With a one-hour TTL, storage for the one-million-token prefix costs $0.50. One normal repeat costs $0.75, while one cached read plus storage costs $0.50 + $0.075 = $0.575. The first subsequent read is profitable by $0.175.

With a four-hour TTL, storage costs $2. At two reads, normal input costs $1.50, so the cache is still more expensive. At three reads, normal input costs $2.25 and cache storage plus reads cost $2 + 3 × $0.075 = $2.225. The third read is the first profitable one, and the margin is only $0.025.

With a 24-hour TTL, storage costs $12. Seventeen ordinary repeats cost $12.75, while storage and seventeen reads cost $13.275. At eighteen reads, the alternatives become $13.50 versus $12 + 18 × $0.075 = $13.35. The eighteenth read is the first profitable point, saving $0.15.

The lesson is not that long TTLs are bad. A long TTL can be appropriate for a large stable document that serves frequent requests throughout a day. The lesson is that storage time is part of the break-even formula. Creating a 24-hour cache “just in case” can erase the read discount when usage is sparse. Because token and storage charges scale together, the threshold count in this simplified model stays the same across eligible prefix sizes, but the money at risk grows with the prefix.

Implicit Gemini caching is not comparable to these deterministic explicit-cache cases. It may save money with no explicit storage decision, but a planner cannot promise the same hit count. Check the response’s cached-token usage and separate the observed result from the explicit TTL simulation.

Official references: Gemini context caching, Gemini explicit caching, and Gemini API pricing.

DeepSeek V4 Flash: measure hit rate instead of inventing a break-even request

DeepSeek’s context cache is automatic. The official guide says persisted prefixes can be reused without application changes, reports prompt_cache_hit_tokens and prompt_cache_miss_tokens, and describes the system as best effort rather than a 100% hit guarantee. Entries that are no longer used are usually cleared within hours to days. The reviewed source did not confirm a minimum prefix token count, so the data records that field as not_confirmed_in_reviewed_source instead of guessing.

Using the approved conservative peak rates for DeepSeek V4 Flash, a cache miss costs $0.44 and a hit costs $0.014 per million input tokens. There is no customer-selected write fee or storage TTL in this comparison, so any realized hit reduces token cost. However, “the first hit saves money” is not a deterministic deployment break-even because the provider does not promise when that hit will occur.

A hit-rate table is more honest. For 100 simulated requests, each with one million reusable prefix tokens, an all-miss baseline costs $44. At a 25% observed hit rate, expected prefix cost is 25 × $0.014 + 75 × $0.44 = $33.35, a saving of $10.65. At 50%, cost is $22.70 and saving is $21.30. At 75%, cost is $12.05 and saving is $31.95. A theoretical 100% hit rate costs $1.40, but it is a boundary case, not a forecast.

Production reporting should calculate hit rate from token counts, not from the number of requests: hit tokens ÷ (hit tokens + miss tokens). A request can contain both matched and unmatched input. Report peak and off-peak billing separately if both rates appear, and do not use the cheaper schedule to understate a budget whose request timing is unknown.

Official references: DeepSeek context caching and DeepSeek API pricing.

A practical measurement protocol

Start with a prompt whose stable prefix is clearly separated from its changing suffix. Keep system instructions, tool definitions, schemas, examples, and shared documents before the breakpoint. Put user input, timestamps, request identifiers, and session-specific data afterward. Confirm that the stable portion exceeds the provider’s minimum where one is documented.

Send a first request and record ordinary input, cache-write, cache-read, and miss tokens from the response fields the provider exposes. Do not fire all test requests concurrently: some caches become reusable only after the first response begins. Then repeat the exact prefix inside the relevant lifetime and vary only the suffix. Run enough requests to observe both hits and misses.

Recalculate cost from billed token categories rather than multiplying the whole prompt by the cached rate. Compare the result with the same requests priced as uncached input. For a storage-priced cache, include the selected TTL even during hours with no reads. For a best-effort cache, report the measured hit-token ratio and a range rather than a guaranteed request count.

Finally, repeat the experiment after a realistic prompt change. Adding a timestamp or modifying a tool schema before the breakpoint may invalidate the earlier entry. A cache that saves money in a laboratory with a frozen prefix can lose money in production if every deployment or tenant changes that prefix.

Decision checklist

Use prompt caching when the shared prefix is eligible, stable, and likely to repeat within the provider’s lifetime. Prefer the shortest lifetime that covers the measured reuse window. Watch billed cache-write and cache-read tokens after each prompt or model change. For Gemini explicit caches, set a deletion policy and include token-hours in the budget. For automatic best-effort caches, base forecasts on measured hit-token percentiles, not the best run.

Avoid caching when the prefix is small, frequently changes, repeats outside the TTL, or contains tenant-specific content that must not be shared under the chosen keying design. Do not add filler solely to cross a minimum without assessing whether the extra input and maintenance are justified. Review provider data-handling and residency terms separately; lower token cost does not answer privacy or compliance questions.

What this experiment does not prove

The results are simulated from official public rates checked on 2026-08-22. They do not measure latency, output quality, provider reliability, regional modifiers, taxes, batch discounts, priority tiers, long-context tiers, or application infrastructure. Gemini’s promotional rate expires, DeepSeek timing can vary, and provider documentation can change. The data is not a real-time feed.

Most importantly, the table is not a model ranking. It does not say that one provider is cheaper for a complete task. It shows how four caching mechanisms change the cost of one repeated prefix under explicit assumptions. Re-run the included formulas with current official rates and your observed usage fields before making a purchasing decision.