[Bug] Weekly all-models cap metering cache_read_input_tokens at full weight vs. 5h bucket discount

Resolved 💬 1 comment Opened May 13, 2026 by bprzybysz Closed Jun 12, 2026

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"}]

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗