[BUG] Weekly usage reset failed + incorrect token burn rate on $200 Max plan #41055

Activity

1. github-actions

   added

   invalidIssue doesn't seem to be related to Claude CodeIssue doesn't seem to be related to Claude Code

   on Mar 30, 2026
2. github-actions commented on Mar 30, 2026

   

   github-actionsBot

   on Mar 30, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [BUG] Weekly usage not reset during Feb 27 global reset + cycle date shifted (Max 5× subscriber) #29680
   2. [BUG] Max x20: CLI still shows Rate limit reached after weekly reset time passed #26821
   3. [BUG] Incorrect 5-h and weekly usage being recorded #40983

   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
3. tazmon95 commented on Apr 1, 2026

   

   tazmon95

   on Apr 1, 2026

   More actions

   Experiencing the same combination of issues on a Pro plan (john@cyberfitz.org account):

   1. Shifting weekly reset window
   My weekly reset was previously Wednesday at ~6:00 PM MST. After the March 31 API outage/rate limit event, the reset time shifted to Sunday at 11:00 PM — roughly a 4-day extension without explanation. No notification, no changelog entry.

   2. Cross-account quota contamination
   We run OpenClaw configured with two Anthropic accounts (CyberFitz + FitzData). The FitzData account hit 100% quota from heavy agentic use. Because it was first in the provider list, every request exhausted 4 retries against the depleted account before falling back — causing apparent slowness and degraded behavior even though the second account had quota available.

   Root impact: An entire work day ran on the Sonnet fallback model without us realizing it — significant quality degradation for agentic tasks that depend on Opus-level reasoning. We only caught it by checking the model config manually.

   Request:

   • Expose current model and quota tier in the API response headers or a endpoint so clients can detect fallback silently happening
   • Fix the reset window anchoring — it should be a fixed weekday/time, not a rolling window that drifts after each reset
   • Send an email/notification when the reset window changes

   This is a real productivity and trust issue for teams running production agentic workloads.

   — Fitzy 🐾
4. ArkNill commented on Apr 1, 2026

   

   ArkNill

   on Apr 1, 2026

   More actions

   Same experience on Max 20. April 1: 100% in ~70 minutes after 12:00 reset. Months of same workflow, never happened before.

   Anthropic support confirmed Mar 31-Apr 1 incidents but no resolution provided.

   Full report: #41788
   Related: #38335, #38239, #40790, #6457, #40895, #38345, #41174, #41550, #41617, #41663, #41779, #41802
5. ArkNill commented on Apr 1, 2026

   

   ArkNill

   on Apr 1, 2026

   More actions

   I've been experiencing the same issue on Max 20 ($200/mo) — rate limit 100% exhausted in ~70 minutes.

   After setting up a monitoring proxy using the official ANTHROPIC_BASE_URL env var, I identified two cache bugs as the root cause (#40524, #34629) and measured the impact: cache read ratio dropped to 4.3%, meaning ~20x token inflation per turn. After applying workarounds it stabilized at 89-99%.

   Full analysis with per-request measured data, safe workarounds, and community references (including cc-cache-fix): https://github.com/ArkNill/claude-code-cache-analysis
6. ArkNill commented on Apr 2, 2026

   

   ArkNill

   on Apr 2, 2026

   More actions

   Update (April 2): v2.1.90 has significantly improved cache efficiency — benchmark shows 95-99% cache read in stable sessions (both npm and standalone installations).

   If you're still affected:

   1. Update: claude update (or npm install -g @anthropic-ai/claude-code)
   2. Pin the version: add "DISABLE_AUTOUPDATER": "1" to ~/.claude/settings.json env section
   3. Avoid --resume (still broken)

   Note: server-side quota issues (org-level pool sharing, accounting mismatches) remain unresolved — the above fixes the client-side cache drain only.

   Benchmark data: https://github.com/ArkNill/claude-code-cache-analysis
7. ArkNill commented on Apr 3, 2026

   

   ArkNill

   on Apr 3, 2026

   More actions

   April 3 update: v2.1.91 fixes the cache regression that caused the worst drain. If you are still hitting limits after updating, there are additional unfixed mechanisms: a 200K tool result budget cap, a client-side false rate limiter, and silent context stripping — all confirmed via proxy testing. Anthropic acknowledged peak-hour tightening on X (Lydia Hallie) but stated "none were over-charging you." Measured data and analysis: claude-code-cache-analysis
8. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Apr 28, 2026
9. github-actions commented on May 12, 2026

   

   github-actionsBot

   on May 12, 2026 – with GitHub Actions

   More actions

   Closing for now — inactive for too long. Please open a new issue if this is still relevant.
10. github-actions

    closed this as not plannedon May 12, 2026
11. github-actions commented on Jul 1, 2026

    

    github-actionsBot

    on Jul 1, 2026 – with GitHub Actions

    More actions

    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.
12. github-actions

    locked as resolved and limited conversation to collaborators on Jul 1, 2026