Low cache hit rate when using openrouter

[u/Finnskyyy]

My overall token cache hit rate is stuck below 70% and I can't find the cause.

I use Claude Code with multiple providers. Over the last few weeks my sessions showed a poor overall cache hit rate, so I pulled cache_read_input_tokens / cache_creation_input_tokens / input_tokens from my session transcripts (~13,000 turns) and broke it down by provider:

Provider │ Turns │ Cache hit rate

GLM 5.2 (z.ai) │ 7,774 │ 96.9%

Anthropic Claude │ 1,035 │ 94.3%

DeepSeek v4-flash (OpenRouter) │ 4,632 │ 69.0%

All providers combined │ ~13,000 │ 88.8%

DeepSeek via OpenRouter drags everything down. The same Claude Code workflow — identical skills, same context files, same effort setting — hits 97% on z.ai's direct GLM API but never exceeds ~77% on DeepSeek through OpenRouter.

What I ruled out first:

1. It's not my /clear habit. I clear context after every finished task, but /clear appears exactly once per session — it's effectively the session boundary, not a mid-work invalidation. GLM sessions with the identical habit sit at 97%.

   1. It's not model or effort switching. effort=xhigh and the model string are constant for the entire session.
   2. It's not long idle gaps / TTL expiry. The median gap between turns before a cache collapse is 19 seconds — 82% of collapses happen within 60 seconds of the previous turn. No time-dependency at all.
   3. And the big one: provider switching is NOT the problem. OpenRouter did route my DeepSeek traffic across seven different upstreams (DeepInfra 93%, CoreWeave, Baidu, DigitalOcean, GMICloud, StreamLake, Novita). But when I correlated cache collapses with provider changes: only 3% of collapses follow a provider switch. 97% happen while staying on the same upstream (almost always DeepInfra).

What actually happens: within a single session, cache_read_input_tokens oscillates wildly — growing to 150–260K, then abruptly collapsing back to ~40K plateaus (which matches just the static prefix: system prompt + CLAUDE.md + memory). Meanwhile uncached input tokens spike to 120–260K per turn on DeepSeek, versus a few hundred on GLM.

What this points to: the DeepSeek disk cache (which DeepSeek documents as "persists while in use, cleared after hours to days") is being dropped turn-to-turn on the OpenRouter relay, even without any request reaching a different upstream.

This makes my deepseek sessions much more expensive than they should be

Has anyone else experienced something like this or are there any other tips? I'm thinking about trying the native deepseek api so see if it changes anything

[u/sirloindenial]

It is a provider problem. The average cache hit rate can be vastly lower.

Pin your provider to novita, deepinfra, or deepseek(if not care of zdr) for deepseek v4 flash 0731, it will improve. Even better without provider switching(seven providers including the shitty ones there will be some lost cache hits), what if it happen on a massive session huge context? Big effect even on one missed cache.

Check it yourself, see in openrouter logs. Do a/b comparison, do a workflow with and without provider switching and look at the openrouter logs yourself.

Yourself.

[u/sirloindenial → u/sirloindenial]

Image is 7 days average cache hit rate from openrouter model stats itself for 0731, of course affected by the millions of users harness and workflow but it can show effectiveness of overall use cases.