Claude Code Cache Hit Rate

In the week of 2026-09-29, Claude Code on Claude models had a median continuation cache hit rate of 96.8% (120 users), and 90.9% over all requests. Most misses came from: account switching (37%), new content in running turns (22%), parallel requests (15%).

Week of 2026-09-29 – 2026-10-05 (UTC)

Key takeaways

  • What is normal: 96.8%, median of 120 users in running conversations; middle half 94.9%–98.1%
  • All requests: 90.9%, including routing, expiry and new chats
  • Largest cause of misses: account switching, 37% of misses
  • Across surfaces: 4.0 points apart, CLI (terminal), Desktop app, Desktop local agent

What cache hit rate is normal for each client

Week of 2026-09-29 – 2026-10-05 (UTC)

  • Continuation hit rate (median user): 96.8%
  • Middle half of users: 94.9%–98.1%
  • Qualifying users: 120 (at least 20 continuation turns in the week)
  • Hit rate over all requests: 90.9%

Claude Code hit rate by surface

The CLI, IDE extension and desktop app of one client send near-identical requests, so their hit rates should be close.

  • CLI (terminal): 97.2% (59)
  • Desktop app: 96.2% (39)
  • Desktop local agent: 96.2% (22)
  • VS Code extension: 96.8% (15)
  • Agent SDK (CLI): 93.3% (7)

Claude Code hit rate by version

A release that changes the request prefix shows a clearly lower hit rate than the others, in the week it ships.

  • 2.1.289: 98.8% (17)
  • 2.1.288: 96.8% (13)
  • 2.1.287: 97.7% (14)
  • 2.1.286: 97.3% (38)
  • 2.1.285: 97.7% (16)
  • 2.1.284: 95.5% (38)
  • 2.1.283: 97.0% (10)
  • 2.1.281: 94.0% (22)
  • 2.1.280: 95.9% (10)

Why is my Claude Code cache hit rate low? Misses by cause

9.1% of this week's input was not read from cache. Here it is by cause, with what you can do about each.

Routed to another upstream account or endpoint: 37% of misses, about 3.4% of all input
A prompt cache lives with the upstream account that served the request. When a relay or multi-account gateway sends the next turn to another account, the whole context is written again. Direct connections to the vendor never show this cause.
New content and prefix changes in a running conversation: 22% of misses, about 2.0% of all input
Content new in a turn can only be written, not read. Connecting or removing MCP servers, or enabling plugins that bring MCP servers, changes the tool definitions and invalidates the cache.
Parallel request (previous one still running): 15% of misses, about 1.4% of all input
Subagents and parallel tool calls send the next request before the previous one ends. A Claude Code fork reads the parent session's cache; a regular subagent has its own system prompt and tools and builds its own cache.
More than 5 minutes idle, cache expired: 12% of misses, about 1.1% of all input
The cache lasts 5 minutes by default and every hit refreshes it for free. If you often pause longer, set CLAUDE_CODE_PROMPT_CACHE_TTL=1h (v2.1.242+); cache writes then cost 2× the input price instead of 1.25×.
Switched model: 8% of misses, about 0.8% of all input
Each model has its own cache. After /model, the next request reads the entire history with no cache hits, even though the content is identical.
New conversation, or idle for over an hour: 6% of misses, about 0.5% of all input
The first request of a new conversation, or one after an hour of idling, has to write the cache again.

A few points of hit rate, several times the bill

At Claude Opus 5.5 official prices, with misses written to the 5-minute cache, the effective cost per million input tokens:

  • This week's median, 96.8%: $0.35 (×1.0)
  • 90%: $0.68 (×1.9)
  • 80%: $1.16 (×3.3)
  • 50%: $2.60 (×7.3)

Run your own numbers in the Claude API cost calculator

Claude Code cache TTL: how long it lasts and what it costs

  • It lasts 5 minutes by default, and every hit refreshes it at no cost.
  • Switch to 1 hour with CLAUDE_CODE_PROMPT_CACHE_TTL=1h (v2.1.242+; CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL for subagents), or ENABLE_PROMPT_CACHING_1H=1 on older versions.
  • Cache writes cost 1.25× the input price (5 minutes) or 2× (1 hour); reads are usually 0.1×, and 0.05× on Opus 5.5 and Sonnet 5.5.
  • Prompts below the minimum length are silently not cached: 512 to 4,096 tokens depending on the model.

Anthropic prompt caching · Claude Code prompt caching · Claude Code environment variables

How to check your Claude Code cache hit rate

  • Run /usage in Claude Code: the Prompt cache (main) line in the Session block shows the request count, the share of input served from cache, cache misses, and whether the cache is still warm.
  • Status line scripts can read the prompt_cache fields; the OpenTelemetry exporter reports cache read and creation tokens per user and session.
  • From the API: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
  • On Wokey, every request in the console's request log shows its cache reads and cache writes.

Claude Code costs and usage

Why hit rates drop behind relays

  • Account switching: the cache belongs to the upstream account, so a turn sent to another account rewrites everything. The most common relay cause; direct connections never have it.
  • Format conversion: translating between Anthropic and OpenAI formats can change the prefix or drop cache_control breakpoints.
  • Claude Code before v2.1.181, on a custom base URL, put a per-request token in the attribution block at the top of the system prompt, which defeats gateways that cache on the request body; upgrade, or set CLAUDE_CODE_ATTRIBUTION_HEADER=0.
  • Self-test: send two requests with the same prefix above the minimum cache length; the second one's cache reads should be close to the prefix length.

Wokey routes a conversation's later requests to the same upstream account whenever it can. From 2026-10-04 to 2026-10-10, ordinary Wokey users hit 92.8% on Claude Opus 5.5 over all requests, against 87.8% for OpenRouter overall.

Compare with OpenRouter cache hit rates · Live: Wokey public cache hit-rate API (last 7 days)

How we measure

  • Real user requests through the Wokey gateway; every Monday at 05:00 UTC we compute the previous Monday-to-Sunday week.
  • Clients are identified from the request User-Agent. Requests from SDKs, HTTP libraries and downstream relays, whose real client is unknown, are left out, as are enterprise accounts.
  • A continuation turn has the same model and upstream account as the previous request of its conversation and starts within 5 minutes of it finishing. Each user's rate is cache reads ÷ input over those turns (input includes cache reads and writes); we report the median over users with at least 20 such turns in the week.
  • A cell is published with at least 5 qualifying users; a change of more than 3 points from last week is checked by hand first.
  • Known biases: Wokey users only; usage habits vary widely; the all-requests rate includes the gateway's own routing loss (the "routed to another upstream account" cause).

FAQ

What is a normal Claude Code cache hit rate?

This week the median of 120 users was 96.8% in running conversations, with the middle half between 94.9% and 98.1%; over all requests it was 90.9%.

Why is my Claude Code cache hit rate low?

This week most misses came from: account switching (37%), new content in running turns (22%), parallel requests (15%). The page lists what to do for each cause.

Does a low cache hit rate burn my Claude plan limit faster?

Yes. In our measurements of Claude plan limits, cache reads use almost none of the limit, while cache writes count about like uncached input. A cached context costs next to nothing; a missed one counts in full again. Per-plan limits are on the Claude usage limits page (/claude-usage-limits).

What are cache read tokens in Claude Code?

The part of the input served from cache, reported as cache_read_input_tokens. In long sessions it is usually over 90% of input and billed at 0.1× the input price (0.05× on Opus 5.5 and Sonnet 5.5); cache_creation_input_tokens is what this request newly wrote to cache.

Is the 1-hour cache worth it?

Usually not. Replaying a day of real Claude traffic on Wokey, switching everything to the 1-hour cache raised total spend by about 15–25% net: writes go from 1.25× to 2× the input price, which costs more than the fewer expiries save. It can pay off only with long contexts and frequent 5–60 minute pauses.

How long does the Claude Code cache last?

Five minutes by default, refreshed free on every hit. CLAUDE_CODE_PROMPT_CACHE_TTL=1h (v2.1.242+) makes it an hour, with cache writes at 2× the input price instead of 1.25×.

Do model switches or subagents break the cache?

Yes. Each model has its own cache, so the request after /model reads everything again; a regular subagent has its own system prompt and tools and builds its own cache, while a fork reuses the parent's.

Why is cache creation so expensive?

Cache writes cost 1.25× (5 minutes) or 2× (1 hour) the input price. The first request of a long conversation, and any request after an account switch or expiry, writes the whole context once and costs clearly more than a normal turn.

Does caching work when Claude Code goes through a relay?

Yes, if the relay passes cache_control through and keeps a conversation on one upstream account. Versions before v2.1.181 on a custom base URL need an upgrade or CLAUDE_CODE_ATTRIBUTION_HEADER=0.