Why Your Anthropic Cache Hit Rate Collapsed: The 5-Minute TTL Regression Explained

What Changed on March 6, 2026

The Anthropic prompt cache has always supported two TTL options: a 5-minute ephemeral cache (the cheap default) and a 1-hour ephemeral cache (a 25% premium on writes, same 90% discount on reads). Until March 6, 2026, the API behavior most production codebases depended on was the 1-hour default for any cache_control block omitting the ttl field. The change rolled the default down to 5 minutes.

The wire format looks identical:

{
  "type": "ephemeral"
}

That object now means 5 minutes of TTL, not 60. To get the old behavior back, you have to write it explicitly:

{
  "type": "ephemeral",
  "ttl": 3600
}

The April 23 postmortem framed the change as "aligning the default with the documentation," and the docs do specify 5 minutes as the default. But the lived experience for thousands of teams was that production code which had run for months suddenly started paying full input rates on every call slower than 5 minutes apart. The gap between intended default and observed default is what generated the postmortem.

The blast radius was largest for three workload patterns: long-running agent loops with human-in-the-loop steps that exceed 5 minutes, scheduled batch jobs that fire every 10-15 minutes against the same prefix, and multi-tenant gateways that round-robin across thousands of distinct prefixes faster than each one can be revisited. Claude Code users hit it inside a single coding session whenever they stepped away from the terminal for a coffee.

Confirming the Regression: Read `usage.cache_read_input_tokens`

Every Anthropic response includes a usage object with four cache-relevant fields. If you're not logging all four on every request, you can't see the regression. Here's the structure:

{
  "usage": {
    "input_tokens": 280,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 38420,
    "output_tokens": 612
  }
}

A healthy cached request looks like the example above: cache_read_input_tokens carries the bulk of the prefix at 10% of input price, input_tokens is small (just the dynamic suffix and user message), and cache_creation_input_tokens is zero. The first request of a window writes the cache:

{
  "usage": {
    "input_tokens": 280,
    "cache_creation_input_tokens": 38420,
    "cache_read_input_tokens": 0,
    "output_tokens": 612
  }
}

A regressed request — same code, same prefix, but the previous cache entry expired — looks like this:

{
  "usage": {
    "input_tokens": 38700,
    "cache_creation_input_tokens": 38420,
    "cache_read_input_tokens": 0,
    "output_tokens": 612
  }
}

Notice both input_tokens and cache_creation_input_tokens are populated. You're paying full input rate on the prefix and writing a fresh cache entry that the next request will probably also miss. This is the worst of both worlds, and it's the financial signature of the TTL regression on a slow-cadence workload.

SELECT
  date_trunc('minute', request_ts) AS minute,
  SUM(cache_read_input_tokens) AS cache_reads,
  SUM(input_tokens) AS uncached_reads,
  SUM(cache_read_input_tokens)::float
    / NULLIF(SUM(cache_read_input_tokens) + SUM(input_tokens), 0)
    AS hit_rate
FROM anthropic_usage
WHERE request_ts > NOW() - INTERVAL '7 days'
GROUP BY 1
ORDER BY 1;

The Four Prefix Drifts That Bust Any TTL

Setting ttl: 3600 only helps if your prefix is byte-identical between calls. The cache key is a hash of the prefix up to and including the cache_control breakpoint, so anything that mutates those bytes invalidates the entry no matter what TTL you set. We've debugged the same four drifts across maybe two dozen client engagements. They account for almost every "I set the TTL but cache_read is still zero" report.

Setting `ttl: 3600` and the Cost Math

Once your prefix is byte-stable, opt back into the 1-hour cache by adding the ttl field on the cache breakpoint:

{
  "model": "claude-opus-4-7-20260315",
  "system": [
    {
      "type": "text",
      "text": "<your 38K-token system prompt>",
      "cache_control": { "type": "ephemeral", "ttl": 3600 }
    }
  ],
  "messages": [
    { "role": "user", "content": "<user query>" }
  ]
}

The 1-hour TTL costs 25% more on writes than the 5-minute default. Reads are still discounted 90% off input price regardless of which TTL you wrote with. The break-even point is the number of reads you complete per write before expiry.

Numbers above use Opus 4.6 input pricing of $3/M tokens. The same logic applies for Sonnet at $3/M and Haiku at $0.25/M; the absolute dollars shrink but the break-even count stays around 3 reads per hour. For most agent loops, RAG workers, and interactive coding sessions, 3 reads per hour is a floor you clear before the second cup of coffee.

The case where 5 minutes is still correct is bursty short-lived prefixes — a one-off batch with N parallel tool calls fired in 30 seconds, then never revisited. Pay the cheaper write, take the discount on the immediate fan-out, and let the cache expire.

For a deeper treatment of when caching is worth the engineering investment in the first place, see our decision guide on caching LLM responses and token cost optimization patterns.

A Debugging Runbook with `curl`

Here's the sequence we run when a client reports a sudden Anthropic cost spike. Every step is something you can paste into a terminal in under a minute.

Step 1: Reproduce the call with full usage logging.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @./repro-prefix.json | jq '.usage'

If cache_read_input_tokens is 0 on the second-and-later calls, you have a problem.

Step 2: Time the second call.

Wait 6 minutes between identical calls. Re-run. If the second call shows cache_creation_input_tokens (a fresh write) instead of cache_read_input_tokens (a hit), the TTL is your issue. Re-run within 4 minutes — if that one hits, you've confirmed the 5-minute window.

Step 3: Pin the TTL.

Edit repro-prefix.json so the cache_control breakpoint reads {"type":"ephemeral","ttl":3600} and re-run the 6-minute spaced test. If you now hit the cache, ship the same change to production. If you still don't hit it, you have a prefix drift — go to step 4.

Step 4: Hash and diff the prefix.

jq -c '{model, system, tools}' call-1.json | sha256sum
jq -c '{model, system, tools}' call-2.json | sha256sum

Different hashes mean the prefix is mutating between calls. Diff the two JSONs to find which field is moving. In our experience the answer is one of the four drifts above 90% of the time.

Step 5: Add the gateway guard.

Once you've fixed the immediate issue, install a permanent guard in your Anthropic client wrapper that logs the prefix hash and the four usage fields per call, alerts on hit rate below a threshold (we use 70% as the floor for steady-state workloads), and exposes both as Prometheus metrics or a dashboard panel.

Architecture Changes That Survive the Next TTL Shift

The TTL regression is a specific instance of a general problem: provider-side defaults can change without notice, and any architecture that depends on those defaults inherits the risk. The pattern we ship to clients now treats provider-side caching as one layer in a stack we control end-to-end, not the load-bearing layer.

Layer 1: Application-layer prefix hashing. We hash the prefix in our gateway and store the hash, the request, and the response in our own cache. Provider-side caching is best-effort discount on top of that, not the primary mechanism.

Layer 2: Semantic similarity caching. A query embedding lookup at threshold 0.93 catches paraphrased duplicates that exact-prefix caching misses entirely. We covered the threshold calibration in our semantic similarity caching guide.

Layer 3: Model routing with cheap-first fallback. Classification and extraction tasks route to Haiku before Opus; long-context refactors route to Opus directly. Our model routing playbook walks through the routing rules in detail.

Layer 4: Provider-side prompt caching with explicit TTLs. Set the TTL on every cache_control block, instrument the four usage fields, alert on hit-rate regressions. The next time Anthropic, OpenAI, or Google flips a default, your alerting catches it the same hour rather than the next billing cycle.

That four-layer stack is the architecture we walk every Particula Tech consulting engagement through when the conversation moves from "we picked a model" to "we have to keep that model affordable in production." The single biggest unlock isn't any individual layer — it's that no single provider-side change can collapse your hit rate to zero without something in your own stack catching it first.

For broader context on when caching is the right answer versus when latency or routing should come first, see our AI Development Tools pillar and the surrounding posts on cost-aware production architecture.

What to Do This Week

Three actions, in order:

If the audit surfaces an order-of-magnitude bill or your engineering team doesn't have the cycles to run the runbook, that's the conversation we have most often this quarter — reach out and we'll help you instrument it.