Does Claude prompt caching save money? The break-even math

How caching is billed

When you mark part of a prompt with cache_control, the first request writes it to the cache and later requests that start with exactly the same text read it. Each is a separate line on the bill, priced from the model's input price:

Every read restarts the cache's lifetime at no extra cost. So requests that share a prefix and start less than 5 minutes apart keep the default cache alive for as long as they keep coming.

The break-even point

Take one cached prompt section that is written once and then read n times while the cache is alive. Measured in "the price of sending that section once":

with caching:    write + n × read
without caching: n + 1
caching wins when n > (write − 1) ÷ (1 − read)

For the 5-minute cache that is n > 0.26 to 0.28 depending on the read price: one read is enough. For the 1-hour cache it is n > 1.03 to 1.11 depending on the read price: two reads. What you save on the cached section, for a few values of n:

Negative means caching cost more than not caching. These percentages are for the cached part of the prompt only; new input and output tokens cost the same either way.

Worked example. A 20,000-token system prompt on Claude Sonnet 5.5 ($2 per million input tokens), used by 10 requests within a few minutes. Without caching: 10 × 20,000 × $2 ÷ 1,000,000 = $0.40. With the 5-minute cache: one write (20,000 × $2 × 1.25 = $0.05) plus nine reads (9 × 20,000 × $0.10 = $0.018) = $0.068, 83% less.

Three ways caching quietly costs you more

• The prefix keeps changing. The cache matches the start of the prompt exactly, byte for byte. A timestamp, a request ID or tools listed in a different order near the top means every request writes a new entry and none reads one. In the example above that is ten writes: $0.50 instead of $0.40, 25% more than not caching at all.
• Requests are further apart than the cache lasts. Requests every 10 minutes never hit a 5-minute cache, so each one pays for a write. Six requests over an hour: 6 × 1.25 = 7.5 "prompt prices" instead of 6. The 1-hour cache fits that pattern: one write and five reads is 2 + 5 × 0.05 = 2.25 on Sonnet 5.5, 62.5% less than not caching.
• The 1-hour cache for traffic that is already continuous. If requests come less than 5 minutes apart, each read keeps the default cache alive anyway. Paying 2× instead of 1.25× for the write buys nothing.

One thing that does not cost you: a prompt shorter than the model's minimum (512 tokens on the current Claude models, up to 4,096 on some older ones) simply isn't cached, with no error and no write charge. You can tell because both cache fields come back as 0.

How to see it in your own numbers

Every response's usage block has the counts: cache_creation_input_tokens (written), cache_read_input_tokens (read) and input_tokens (neither). If the reads stay at zero across requests that should share a prefix, something at the start of the prompt is changing. A healthy setup reads many tokens for every token it writes.

This script adds it up from your logs and compares what you paid with what the same tokens would have cost with no caching. It reads JSON Lines files with a model and a usage block on each line (log response.model and response.usage.to_dict() from the Python SDK), and also Claude Code's own logs in ~/.claude/projects, priced at API rates. It prints numbers only and sends nothing anywhere. (Download it, or get it with the other scripts on GitHub.)

python3 claude_cache_savings.py ~/.claude/projects

Requests:              2
Input tokens:          40020  (50% read from cache, 50% written to cache)
Reads per written token: 1.0
You paid:              $0.0580
Without caching:       $0.0860
Caching saved:  $0.0280 (32.5%)

That sample is two Sonnet 5.5 requests that shared a 20,000-token prefix: one write, one read, the 32.5% from the table. The core of it:

WRITE_5M, WRITE_1H = 1.25, 2.0

def costs(model, usage, prices=PRICES):
    """(paid, without caching) in USD for one request, or None if the model has no price."""
    p = prices.get(model)
    if p is None:
        return None
    new_in = usage.get("input_tokens") or 0
    writes = usage.get("cache_creation_input_tokens") or 0
    w1h = (usage.get("cache_creation") or {}).get("ephemeral_1h_input_tokens") or 0
    w5 = max(0, writes - w1h)
    read = usage.get("cache_read_input_tokens") or 0
    out = usage.get("output_tokens") or 0
    paid = (new_in * p["input"] + w5 * p["input"] * WRITE_5M + w1h * p["input"] * WRITE_1H
            + read * p["cache_read"] + out * p["output"]) / 1_000_000
    no_cache = ((new_in + writes + read) * p["input"] + out * p["output"]) / 1_000_000
    return paid, no_cache

We tested it on 33 usage blocks across 11 models, including 1-hour cache writes: the cost it computes matches NeverPayTwice's own engine every time. It keeps one record per response when Claude Code logs the same response several times, and it lists any model it has no price for instead of counting it as free. It uses standard rates only; the Batch API, US-only inference and fast mode change prices and are not applied.

Or let something record it for you

NeverPayTwice is a small app we make. Its live meter sits on your own computer between your code and the API (ANTHROPIC_BASE_URL=http://127.0.0.1:8098/anthropic) and keeps a receipt for every request with new input, cache writes and cache reads priced separately, so you can see when cache writes are not followed by reads. It never blocks or changes a request, and API keys are never stored. It also flags every time you paid again for a request you had already bought. Works with Anthropic, OpenAI, Google Gemini and compatible APIs. Mac, Windows or Linux, $9 one time.

Sources: Anthropic's prompt caching guide (write and read prices, cache lifetime and refresh, minimum lengths) and pricing page, checked November 14, 2026. Prices can change; check the current pages if something doesn't match.