[Bug] Workflow interrupted due to weekly usage limit spike, cached tokens not applied on resume

The same thing happened: the weekly session supposedly ended, although it was actually at 68%. Now everything is back, but even Sonnet wouldn't start for 3 hours.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46310
2. https://github.com/anthropics/claude-code/issues/64974
3. https://github.com/anthropics/claude-code/issues/42338

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Found 3 possible duplicate issues: 1. [[Bug] Usage spike after rate limit reset with resumed session #46310](https://github.com/anthropics/claude-code/issues/46310) 2. [[BUG] Massive token/quota spike and Prompt Caching failure after 1M context hotfix #64974](https://github.com/anthropics/claude-code/issues/64974) 3. Session resume (--continue) invalidates entire prompt cache, causes massive rate limit consumption #42338 This issue will be automatically closed as a duplicate in 3 days. If your issue is a duplicate, please close it and 👍 the existing issue instead To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with Claude Code

Closing as a duplicate of #42338 for the cache part — same end result (full re-cache on continuation, counted as new input tokens instead of cache_read).
One difference worth noting for #42338: in my case there was no manual --resume or --continue. The session was involuntarily interrupted by the weekly usage limit hitting 100%, and the cache was invalidated the same way on continuation. So the cache-prefix invalidation doesn't seem limited to the manual resume path — an interruption-driven continuation triggers it too.
Separately, the premature limit cutoff (limit showing 100% for hours, then dropping back to 70%; @mlch reporting a block at 68% with Sonnet unavailable for ~3h) looks like a distinct issue not covered by #42338. Closest match #46310 was closed as "not planned", so I'll leave that aside here unless I can gather harder data (usage-meter screenshot with timestamps, JSONL excerpt).

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.