Codex Cache Hit Rate

Key takeaways

• What is normal: 96.0%, median of 38 users in running conversations; middle half 93.1%–97.2%
• All requests: 93.6%, including routing, expiry and new chats
• Largest cause of misses: new content in running turns, 73% of misses
• Across surfaces: 2.1 points apart, Desktop app, Terminal UI, codex exec (non-interactive)

What cache hit rate is normal for each client

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

• Continuation hit rate (median user): 96.0%
• Middle half of users: 93.1%–97.2%
• Qualifying users: 38 (at least 20 continuation turns in the week)
• Hit rate over all requests: 93.6%

Codex 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.

• Desktop app: 95.7% (27)
• Terminal UI: 96.0% (8)
• codex exec (non-interactive): 97.8% (6)

Codex 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.

• 0.160.0: 96.2% (21)
• 0.159.2: 96.1% (9)
• 0.159.0-alpha.12.1: 95.7% (5)
• 0.158.0-alpha.2.1: 93.5% (7)

Why is my Codex cache hit rate low? Misses by cause

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

New content and prefix changes in a running conversation: 73% of misses, about 4.7% of all input

OpenAI's cache needs the entire prefix to match. Changing reasoning effort, tools or output format mid-session, or Codex compacting the history, changes the prefix. This is the largest source of Codex cache misses.

New conversation, or idle for over an hour: 11% of misses, about 0.7% of all input

The first request of a new conversation, or one after an hour of idling, has to write the cache again.

Routed to another upstream account or endpoint: 10% of misses, about 0.6% 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.

More than 5 minutes idle, cache expired: 3% of misses, about 0.2% of all input

On GPT-5.6 and later the cache lasts 30 minutes by default, counted from the last write or reuse; older models usually drop it after 5–10 idle minutes.

Parallel request (previous one still running): 1% of misses, about 0.1% of all input

A request sent before the previous one finished (subagents, parallel tool calls) cannot read the cache the previous one is still writing.

Switched model: 1% of misses, about 0.1% of all input

Each model has its own cache, so the first request after a model switch reads the whole history again.

Codex cache TTL: how long it lasts and what it costs

• OpenAI caches prompt prefixes automatically, without client breakpoints; GPT-5.6 and later cache prompts from 1,024 tokens.
• GPT-5.6 and later keep it 30 minutes by default, from the last write or reuse. Older models keep in-memory entries for about 5–10 idle minutes, up to an hour; some support 24-hour retention.
• Cached input is usually billed at 0.1× the input price, 0.05× on GPT-6.1 Sol; GPT-5.6 and later charge 1.25× for cache writes.
• Codex sends the session ID as prompt_cache_key (per its source code), so a session's requests are routed to the same cache.

OpenAI prompt caching · OpenAI cache miss diagnostics · Codex source (prompt_cache_key) · Codex issue #35416: changing reasoning effort misses

How to check your Codex cache hit rate

• When the Codex CLI exits it prints the session's token usage; the "+ N cached" part is input read from cache (current behaviour, not in the docs).
• From the API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; GPT-5.6 and later also report cache writes.
• The turn.token_usage OpenTelemetry metric includes a cached_input type.
• On Wokey, every request in the console's request log shows its cache reads and cache writes.

OpenAI cache miss diagnostics

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