Prompt Caching Savings Calculator: When Caching Pays Off

Prompt caching can make a repeated, input-heavy LLM workflow much cheaper, but the headline discount is not the same as the realized saving. A cache write may cost more than normal input, only an identical prefix is reusable, and an expired entry turns the next request into another write. The useful question is not “Does this provider support caching?” It is “How many paid cache reads will this stable prefix produce before it changes or expires?”

This guide gives you the equations and inputs needed for a prompt caching calculator. Prices and product behavior were verified against official OpenAI and Anthropic documentation on 2026-07-24. Recheck those sources before approving a production budget because model prices, eligible models, token thresholds, and cache controls can change.

Separate cacheable and variable tokens

A request is rarely either fully cached or fully uncached. Split its input into:

• Cacheable prefix tokens (C): stable tool definitions, system instructions, examples, reference documents, or conversation history that can be identical across requests.
• Variable input tokens (V): the latest user request, timestamps, request IDs, retrieved passages, or other content that changes.
• Output tokens (O): generated tokens. Prompt caching does not discount output.

For N requests, the no-cache cost is:

No-cache cost = N × ((C + V) × Pinput + O × Poutput) / 1,000,000

Here, Pinput and Poutput are the model’s prices per million tokens. The cached case needs two more prices: Pwrite for creating the cached prefix and Pread for reusing it.

Cached cost = (W × C × Pwrite + H × C × Pread + N × V × Pinput + N × O × Poutput) / 1,000,000

W is the number of cache writes and H is the number of hits, so N = W + H when every request attempts to use the same cacheable prefix. Savings are:

Savings = No-cache cost - Cached cost

The output and variable-input terms cancel when you compare the same workload. That is why the economic decision rests mainly on prefix size, write price, read price, and actual reuse.

Calculate the break-even reuse count

For one cache write followed by R reads of the same prefix, caching beats ordinary input when:

Pwrite + R × Pread < (R + 1) × Pinput

Solving for reuse gives:

R > (Pwrite - Pinput) / (Pinput - Pread)

Suppose a provider charges 1.25 times the normal input price for a write and 0.10 times for a read. The threshold is:

R > (1.25 - 1.00) / (1.00 - 0.10) = 0.278

Because reuse is a whole number, one successful read after one write is enough to produce a net token-cost saving. That does not mean every caching implementation saves money. If the prefix changes before the second request, or the second request arrives after expiry, you pay repeated write premiums without receiving the discounted read.

The embedded LLM API Cost Calculator should therefore accept cacheable tokens, requests, write price, read price, and measured hit rate separately. Do not model “caching enabled” as a flat percentage discount. If you need a broader cost model that also includes output and request volume, see the guide to cutting LLM token spend without guessing.

Price TTL and reuse assumptions correctly

OpenAI’s current GPT-5.6 Sol model page lists $5 per million input tokens, $0.50 per million cached-input tokens, and $30 per million output tokens. It also states that cache writes cost 1.25 times uncached input. Source verified 2026-07-24: OpenAI GPT-5.6 Sol model documentation.

Anthropic prices cache behavior explicitly. Its current pricing table lists, for example, Claude Sonnet 4.6 at $3 per million base input tokens, $3.75 for five-minute cache writes, $6 for one-hour writes, $0.30 for cache hits and refreshes, and $15 for output. Those columns correspond to the general multipliers of 1.25 times base input for a five-minute write, 2 times for a one-hour write, and 0.1 times for a read. Source verified 2026-07-24: Anthropic pricing.

TTL changes the expected write count. Anthropic’s default cache lifetime is five minutes and is refreshed when the cached content is used; a one-hour option is available at the higher write price. Its docs also state that a cache hit requires a matching prefix through the breakpoint. Source verified 2026-07-24: Anthropic prompt caching documentation.

Use workload timing, not just daily request totals. Sixty calls arriving once per minute may sustain one cache entry. Sixty calls arriving once per hour may cause sixty writes. For a calculator, estimate cache lifecycles as:

Expected writes = number of distinct stable prefixes × active TTL windows per prefix

Then use observed hits if they are available. A theoretical hit rate based only on request count will overstate savings when traffic is bursty, routed across changing models, or split across isolated workspaces.

Work through a monthly example

Consider 100,000 monthly requests to GPT-5.6 Sol. Each request contains a 10,000-token stable prefix, 1,000 variable input tokens, and 500 output tokens. Assume 90% of prefix attempts are cache reads and 10% are writes or misses.

Without caching:

• Total input: 100,000 × 11,000 = 1.1 billion tokens
• Input cost: 1,100 × $5 = $5,500
• Output cost: 50 million × $30 = $1,500
• Total: $7,000

With caching:

• Cache writes: 100,000 × 10% × 10,000 = 100 million tokens
• Write cost: 100 × ($5 × 1.25) = $625
• Cache reads: 100,000 × 90% × 10,000 = 900 million tokens
• Read cost: 900 × $0.50 = $450
• Variable input cost: 100 million × $5 / 1 million = $500
• Output cost: $1,500
• Total: $3,075

Estimated monthly saving: $3,925, or about 56.1% of the original total bill.

The marked headline figures recalculate from the four workload inputs; the intermediate arithmetic and hit-rate table remain the fixed 90% read-rate example.

That percentage is lower than the 90% cached-input discount because variable input, output, and cache writes remain billable. The same assumptions produce the following comparison:

Prefix cache-read rate	Requests billed as writes	Requests billed as reads	Estimated total	Saving vs. $7,000 baseline
No caching	0	0	$7,000	$0 (0%)
0%	100,000	0	$8,250	-$1,250 (-17.9%)
50%	50,000	50,000	$5,375	$1,625 (23.2%)
90%	10,000	90,000	$3,075	$3,925 (56.1%)

At a 0% read rate, repeated 1.25-times writes make the cached attempt more expensive than ordinary input. Treat the table as arithmetic, not a forecast: your tokenizer, traffic shape, routing, and prefix stability determine the result.

Batch processing can change the comparison again. Keep the cache calculation and batch discount as separate line items, then verify whether the selected model and endpoint allow the combination. The OpenAI Batch versus Claude Message Batches comparison explains why discounts should not be stacked automatically.

Find false savings caused by misses

A configured cache is not evidence of a hit. Common causes of false savings include:

• A timestamp, request ID, user-specific value, or reordered JSON field appears before the breakpoint.
• Tool definitions, model IDs, images, or system instructions change between calls.
• The supposedly reusable prefix is shorter than the provider’s model-specific minimum.
• Traffic returns after the TTL, or parallel follow-up requests arrive before the initial write becomes available.
• A router sends otherwise identical prompts to different models, regions, projects, or workspaces.

Anthropic’s current documentation lists model- and platform-specific minimum cacheable lengths rather than one universal number. For example, it lists 1,024 tokens for several active Sonnet and Opus models, 4,096 for Claude Haiku 4.5, and other thresholds for newer or platform-specific models. Shorter marked prompts may proceed without caching rather than fail. Verify the exact model and platform in the official cache limitations before entering a minimum in a calculator.

Prefix layout is usually the first fix: place stable tools, instructions, and reference material before variable content. If the hit rate remains unexpectedly low, use the diagnostic sequence in how to fix prompt cache misses before changing the financial model.

Instrument a telemetry checklist

Record cache behavior per request and aggregate it by model, route, prompt version, workspace, and time bucket. At minimum, track:

• Total input, cache-write, cache-read, variable-input, output, and reasoning tokens where applicable.
• Cache hit rate by both request count and token count.
• Effective write/read price and processing tier at request time.
• Prefix version or hash generated without storing sensitive prompt content in logs.
• TTL selected, time since the last matching request, and expiry-driven rewrites.
• Miss reason, model or route changes, and deployment events.
• Estimated cost without caching, actual cached cost, net saving, and latency to first token.

For OpenAI, current guidance identifies cached_tokens and cache_write_tokens as the fields to monitor for GPT-5.6 caching. Anthropic responses expose cache_creation_input_tokens and cache_read_input_tokens, with a cache-creation breakdown for five-minute and one-hour writes. These field names were verified in the official documentation on 2026-07-24; preserve raw billing exports as the source of truth if SDKs rename or nest them differently.

Review savings weekly at first. A healthy request-level hit rate can still hide poor economics if large prefixes miss while small prefixes hit. Token-weighted hit rate is the more useful operational measure.

Prompt caching FAQ

Does a 90% cache discount reduce my entire API bill by 90%?

No. It applies only to eligible cached input tokens. Writes, variable input, output, tools, reasoning, and other billable features may remain at separate rates.

Should I use a longer TTL?

Use it when follow-up requests commonly arrive after the shorter TTL and the expected reads repay the higher write price. Compare lifecycles from real timestamps; do not choose a one-hour TTL only because it sounds safer.

Can caching change the model’s answer?

Prompt caching is intended to reuse processing for an identical prefix, not to alter the prompt. Anthropic states that output generation is unaffected. You should still run quality regression tests whenever you change prompt ordering or breakpoint placement.

What is the most important calculator output?

Show monthly cached cost, no-cache baseline, net saving, break-even reads, token-weighted hit rate, and every assumption. A single “you save 90%” badge hides the variables most likely to invalidate the estimate.

Related guides

• Cut LLM token spend without guessing for a broader input-and-output cost model.
• Fix prompt cache misses for prefix-layout and telemetry diagnostics.
• Semantic caching for LLM applications for the separate case where requests are similar rather than prefix-identical.
• LLM API cost calculator for comparing total workload costs beyond caching.

Primary sources

All sources below were checked on 2026-07-24:

• OpenAI: GPT-5.6 Sol model and token pricing
• Anthropic: Claude API pricing
• Anthropic: Prompt caching behavior, TTLs, limits, and usage fields