Prompt caching prices in Oct 2026: Claude, OpenAI 12-hour and Gemini math

Three vendors changed caching in the last few weeks, and the changes pull in different directions. Claude Sonnet 5.5 cache reads got cheaper, OpenAI added a 12-hour cache with an expensive write, and Gemini 4 Argon only caches implicitly. If you run a long system prompt or a big shared context, the right choice depends on how far apart your requests are, so here is the break-even math and a script that runs it.

All prices below were read from vendor pages on 2026-10-30 and 2026-10-31 and will change; check them before you budget. The calculator is my own code. I ran it on 2026-10-31 and the output is pasted unedited. Nothing here made a live API call.

What changed, with sources

The full price rows I used:

Two OpenAI details worth reading in the prompt caching guide (I read the raw page, not just a summary). For GPT-5.6 and later, a default write costs 1.25x the uncached input rate with a 30-minute lifetime. In the Responses API you can choose a 12-hour minimum lifetime at 2.5x. Reads cost 0.1x on most of these models and 0.05x on GPT-6.1 Sol and GPT-6.1 Terra, whatever lifetime you picked. The guide also says cache-write pricing is not an extra fee: input tokens use the uncached, cached or cache-write rate. The 12-hour option is set per cache breakpoint with "ttl": "12h" in the guide's example.

Anthropic's pricing page puts the Sonnet 5.5 multiplier at 0.05x and says a 5-minute write (1.25x) pays off after one read, a 1-hour write (2x) after two. Pricing for Haiku 5.5 depends on prompt length, and the page says that count includes cache reads and writes, so a long cached prefix can push a request into the higher tier.

The break-even rule

For a write multiplier w and a read multiplier r (both relative to the normal input price), caching beats no caching after N reads when:

w + N * r  <  (N + 1) * 1.0

So N > (w - 1) / (1 - r). With w = 1.25, r = 0.05 that's 0.26, so one read is enough. With w = 2.5, r = 0.05 it's 1.58, so two reads. The cheaper reads get, the less the read price matters and the more the write premium and the cache lifetime decide the outcome.

That's the main point of this post. At 0.05x reads, the read price is almost irrelevant. What decides your bill is whether your requests arrive before the cache expires.

The calculator

This models only the cached prefix (20,000 tokens, an adjustable constant). Fresh input and output tokens cost the same either way, so leave them out of the comparison.

My modelling assumptions, which are mine and not vendor statements:

• Anthropic: every cache hit refreshes the time-to-live. The pricing table is headed "cache hits and refreshes", but check the caching docs for the exact refresh rule before relying on it.
• OpenAI: the lifetime is a minimum counted from the write, and I assume reads don't extend it. That makes OpenAI's number a conservative (high) estimate; the real cost may be lower if entries last longer than the minimum.
• Gemini: implicit caching is not guaranteed, so I show per-request prefix cost at 0, 50 and 90 percent hit rates. Those hit rates are illustrative inputs, not measurements.

PREFIX_TOKENS = 20_000

# name: (input $/M, write multiplier, ttl minutes, read multiplier, refresh_on_hit)
OPTIONS = {
    "Anthropic Sonnet 5.5, 5m write":   (2.00, 1.25, 5, 0.05, True),
    "Anthropic Sonnet 5.5, 1h write":   (2.00, 2.00, 60, 0.05, True),
    "Anthropic Haiku 5.5, 5m write":    (0.10, 1.25, 5, 0.10, True),
    "Anthropic Haiku 5.5, 1h write":    (0.10, 2.00, 60, 0.10, True),
    "OpenAI GPT-6.1 Sol, 30m write":    (2.00, 1.25, 30, 0.05, False),
    "OpenAI GPT-6.1 Sol, 12h write":    (2.00, 2.50, 720, 0.05, False),
}

def break_even_reads(write_mult, read_mult):
    n = 0
    while write_mult + n * read_mult >= (n + 1) * 1.0:
        n += 1
    return n

def schedule_cost(arrivals_min, input_price, write_mult, ttl, read_mult, refresh):
    cost, valid_until = 0.0, None
    for t in arrivals_min:
        if valid_until is not None and t <= valid_until:
            cost += PREFIX_TOKENS / 1e6 * input_price * read_mult
            if refresh:
                valid_until = t + ttl
        else:
            cost += PREFIX_TOKENS / 1e6 * input_price * write_mult
            valid_until = t + ttl
    return cost

def uncached(arrivals_min, input_price):
    return len(arrivals_min) * PREFIX_TOKENS / 1e6 * input_price

Haiku 5.5's read multiplier is 0.1x ($0.01 on a $0.10 input), which is why its break-even and curves look different from Sonnet's. I priced Haiku only for prompts up to 100k tokens.

Break-even output

Break-even: reads needed after one write to beat no caching
  Anthropic Sonnet 5.5, 5m write     write 1.25x read  0.05x -> 1 read(s)
  Anthropic Sonnet 5.5, 1h write     write  2.0x read  0.05x -> 2 read(s)
  Anthropic Haiku 5.5, 5m write      write 1.25x read   0.1x -> 1 read(s)
  Anthropic Haiku 5.5, 1h write      write  2.0x read   0.1x -> 2 read(s)
  OpenAI GPT-6.1 Sol, 30m write      write 1.25x read  0.05x -> 1 read(s)
  OpenAI GPT-6.1 Sol, 12h write      write  2.5x read  0.05x -> 2 read(s)

Three traffic shapes

Same 20,000-token prefix, three arrival patterns. "vs uncached" is the cost as a share of paying full input price every time. Over 100% means caching lost money.

burst: 10 requests, 1 min apart
  Anthropic Sonnet 5.5, 5m write        0.0680         17%
  Anthropic Sonnet 5.5, 1h write        0.0980         25%
  Anthropic Haiku 5.5, 5m write         0.0043         21%
  Anthropic Haiku 5.5, 1h write         0.0058         29%
  OpenAI GPT-6.1 Sol, 30m write         0.0680         17%
  OpenAI GPT-6.1 Sol, 12h write         0.1180         30%

steady: 24 requests, 20 min apart (8 h)
  Anthropic Sonnet 5.5, 5m write        1.2000        125%
  Anthropic Sonnet 5.5, 1h write        0.1260         13%
  Anthropic Haiku 5.5, 5m write         0.0600        125%
  Anthropic Haiku 5.5, 1h write         0.0086         18%
  OpenAI GPT-6.1 Sol, 30m write         0.6240         65%
  OpenAI GPT-6.1 Sol, 12h write         0.1460         15%

sparse: 8 requests, 90 min apart (10.5 h)
  Anthropic Sonnet 5.5, 5m write        0.4000        125%
  Anthropic Sonnet 5.5, 1h write        0.6400        200%
  Anthropic Haiku 5.5, 5m write        0.0200        125%
  Anthropic Haiku 5.5, 1h write        0.0320        200%
  OpenAI GPT-6.1 Sol, 30m write         0.4000        125%
  OpenAI GPT-6.1 Sol, 12h write         0.1140         36%

The columns shown are cost in dollars and share of uncached cost.

What the numbers say

• Burst traffic: the cheap short write wins. A 12-hour write is a waste when everything arrives within minutes, because you paid 2.5x for lifetime you didn't use.
• Steady traffic with gaps of 20 minutes: a 5-minute Anthropic write loses money (125%), because every request lands after expiry and pays a write premium with no reads. The 1-hour write cuts it to 13%. OpenAI's 30-minute default is borderline here, and my conservative no-refresh assumption puts it at 65%.
• Sparse traffic with 90-minute gaps: Anthropic's 1-hour option also loses (200%), because the gap is longer than the lifetime. OpenAI's 12-hour write is the only option in this table that wins (36%), which is exactly the case it was built for.
• The rule of thumb: pick the shortest lifetime that is longer than your typical gap. Anything longer is overpaying; anything shorter is paying the write premium on every request.

What the Sonnet read price change is worth

At 0.05x versus 0.1x, the cut matters for volume. The calculator's last two lines for Sonnet 5.5: one million cached tokens read 1,000 times costs $200.00 at the old $0.20 rate and $100.00 at the new $0.10 rate. That's a real saving for an agent loop that re-reads a big context on every step. It does not change the break-even count, as both rates are cheap relative to the write premium.

Gemini 4 Argon: no write fee, but no guarantee

Google's page lists the cache price at $0.10 per million through November 30 and $0.20 from December 1, with input at $2.00 then $4.00, and says explicit caching is not supported. I did not find (and so won't state) how Google decides what gets a hit, or whether any storage charge applies; the pricing page shows none for this model. Per-request prefix cost for a 20,000-token prefix, at illustrative hit rates:

Gemini 4 Argon implicit caching: cost of the prefix per request at a given hit rate
  through Nov 30  hit 0%: $0.0400  hit 50%: $0.0210  hit 90%: $0.0058
  from Dec 1      hit 0%: $0.0800  hit 50%: $0.0420  hit 90%: $0.0116

The more important line is the price doubling on December 1: at the same hit rate, your cached-prefix cost doubles. Log your real hit rate from usage metadata before you plan around any of these hit rates.

A decision procedure

1. Measure the gap between requests that share a prefix (the median and the 90th percentile, not the average).
2. Pick the shortest cache lifetime that covers the 90th percentile gap.
3. Compute w and r for that option and the break-even from the formula. If your prefix is reused fewer times per lifetime than the break-even, don't cache it.
4. Run the calculator with your real prefix size and arrival times. Replace PREFIX_TOKENS and the arrival lists.
5. In production, verify hits using the provider's usage fields. Anthropic's cache diagnostics (out of beta Sep 23) and OpenAI's prompt cache diagnostics (generally available Sep 8, per its changelog) exist for debugging misses; the long-running agent caching post shows the hit-check routine.
6. Re-check prices monthly. They moved twice in the last month.

For background on how to structure prompts so the prefix stays stable, see prompt caching strategies for Anthropic and OpenAI. For a wider bill review, use the Claude API bill checklist. If you want to translate the saving into per-request cost, the cost per 1,000 requests post has the template.

What I couldn't verify

• Whether an OpenAI cache hit extends the 12-hour lifetime. The guide calls it a minimum lifetime; I assumed no extension.
• Anthropic's refresh-on-hit behaviour is my reading of the pricing table heading, not a quote from the caching docs.
• Gemini's rules for when an implicit hit happens, and whether explicit-cache storage fees apply to other models. I only report the Argon page.
• The calculator ignores output tokens, batch discounts, tool results that change the prefix, and the 100k-token tier jump on Haiku 5.5.
• I did not make any API call. Hit rates for Gemini are illustrative inputs.