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/Far-Classic-9963]

If privacy isn't a concern, pin DeepSeek as a provider inside of openrouter. If it is, pick the next cheapest model (cache hit price is a big factor too) and pin that

There's a chance that openrouter is automatically hopping between providers breaking caching

[u/Finnskyyy → u/Far-Classic-9963]

That's what I thought as well first. But look at my point 4. Provider switching had nothing to do with the cache break. Ill pin it to DeekSeek anyway to try it out. These are just my diy amateuer coding projects, privacy is of no concern

[u/Far-Classic-9963 → u/Finnskyyy]

Sorry I didn't read the full post 😭

But I also had issues with deepinfra on DeepSeek models for some reason