[Bug] Weekly all-models cap metering cache_read_input_tokens at full weight vs. 5h bucket discount
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"}]This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗