claude-code - 💡(How to fix) Fix [Bug] Weekly all-models cap metering cache_read_input_tokens at full weight vs. 5h bucket discount [1 participants]

Bug Description [Data point] Weekly all-models cap depleting abnormally fast while 5h session cap behaves normally — Max 5x, Opus 4.7, v2.1.140

Environment

• Plan: Claude Max 5x ($100/mo)
• Claude Code: v2.1.140
• Primary model: claude-opus-4-7
• Sub-agents: claude-sonnet-4-6 via delegation
• MCP: Serena (language-server symbol queries; high cache-read volume by design)

Observed asymmetry

• 5-hour session cap: behaves as expected. Since Serena was reintroduced (configuration bug fixed mid-week), I have not hit the 5h ceiling in any session, consistent with Serena's intended token-efficiency profile.
• Weekly all-models cap: depleting noticeably faster than my historical baseline, despite identical or lighter per-session usage and despite never hitting the 5h cap.

The two buckets are diverging. Per-session feels healthy; weekly burns down as if cache-read discounting isn't being applied at the weekly aggregation layer.

Hypothesis cache_read_input_tokens may be metered at reduced weight in the 5-hour bucket but at full weight (or near-full) in the weekly all-models bucket. That would exactly produce the pattern observed: longer individual sessions, but the weekly cap exhausting faster than the per-session experience would predict.

Local signal ~/.claude/stats-cache.json shows 34,840,528 cacheReadInputTokens against only 3,560 fresh input + 26,392 output for a representative comparable session. Per-session that's fine; aggregated across a week, if those cache reads are counted at full weight in the weekly bucket, that alone would explain the accelerated weekly depletion.

Not a duplicate Related to but distinct from #49302 (Opus 4.7 5h-bucket metering) and #46829 (cache TTL regression). This report is specifically about the weekly bucket behaving inconsistently with the 5h bucket for the same cache_read_input_tokens.

Environment Info

• Platform: darwin
• Terminal: windsurf
• Version: 2.1.139
• Feedback ID: 1b5c08cb-68ba-44e1-b35c-86739fe180a1

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/blaisem4/.local/share/claude/versions/2.1.139 (expected in multi-process scenarios)\n    at z16 (/$bunfs/root/src/entrypoints/cli.js:2662:2257)\n    at tRH (/$bunfs/root/src/entrypoints/cli.js:2662:1337)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-12T12:34:40.329Z"},{"error":"Error: EISDIR: illegal operation on a directory, read '/Users/blaisem4/src/oraxis'\n    at F$H (/$bunfs/root/src/entrypoints/cli.js:1574:144)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-13T16:07:36.453Z"},{"error":"Error: Request was aborted.\n    at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-13T16:27:47.192Z"},{"error":"Error: Request was aborted.\n    at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-13T18:23:04.432Z"},{"error":"Error: Request was aborted.\n    at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-05-13T18:31:29.181Z"}]