Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Bug report — Weekly usage limit reset day drifted Thu → Sat on Max (5x), with timer rebase event

Account: [email protected] Plan: Max (5x) Filed: April 30, 2026 Filing path: /bug from inside Claude Code (auto-attaches account context to GitHub tracker)

Summary

The weekly reset for this Max (5x) account has drifted across three different anchor days with inconsistent per-tier behavior, culminating in a backend rebase event that collapsed the two formerly-independent weekly timers onto a single new anchor. The most recent cycle ran 8 days 12 hours instead of the documented 7 days.

Drift timeline:

• Original (per personal usage tracker, established before March 2026): All models Tue 7:00 PM ET / Sonnet only Tue 9:00 PM ET (different times, same weekday)
• Apr 21, 2026 (verified by screenshot): All models Thu 3:00 PM ET / Sonnet only Thu 9:00 PM ET (both shifted to Thursday, Sonnet kept its 9 PM time, All models acquired a NEW 3 PM time)
• Apr 30, 2026 (verified by screenshot): All models Sat 3:00 AM ET / Sonnet only Sat 3:00 AM ET (both rebased to identical anchor — formerly-independent timers collapsed)

That's not anchor drift in one direction — it's two distinct backend rebase events with inconsistent per-tier handling. Evidence of either un-announced backend migrations or a recurring bug in cycle-anchor recomputation.

Evidence

Baseline — personal usage tracker (Notion), pre-March 2026

• All models reset: Tue 7:00 PM ET
• Sonnet only reset: Tue 9:00 PM ET
• Two timers were on different times within Tuesday. Documented in personal Claude Usage Tracker page.

Screenshot A — Tue Apr 21, 2026 @ 10:15 AM ET

• All models: 39% used. Resets Thu 3:00 PM ET
• Sonnet only: 2% used. Resets Thu 9:00 PM ET
• The two timers were on different reset times (six hours apart) but the same weekday.

Screenshot B — Wed Apr 30, 2026 @ 6:37 PM ET

• All models: 35% used. Resets Sat 3:00 AM ET — shifted weekday and time
• Sonnet only: 6% used. Resets Sat 3:00 AM ET — also shifted, now identical to All models
• The two timers are now rebased onto a single anchor.

Local usage tracker (independent)

A workstation cron job (claude-usage-alert.py, hourly) tracks weekly usage and was working through the prior cycle.

• Last verified successful reset: Thu Apr 23, 2026 @ 3:00 PM ET
• Cycle just-closed (Apr 23 → Apr 30): $285.27 spent across 7 days, $286.84/wk run rate
• Local script anchor: RESET_WEEKDAY = 3 (Thursday). UI anchor migrated to Saturday without any visible reset event or notification.

Cycle math

Hypothesis

A backend reset/recalc event between Apr 21 and Apr 30 collapsed two formerly-independent weekly timers (All models at Thu 3 PM, Sonnet only at Thu 9 PM) onto a single new anchor (Sat 3 AM). Possible causes:

• Intentional but un-announced backend migration consolidating per-tier timers
• Bugfix or rate-limit-system change that recalculated cycle anchors using different logic (fixed-weekday vs floating-from-first-use)
• Carry-over from the documented February 2026 prompt-caching-bugfix incident pattern that shifted Wed → Fri without zeroing the counter

Related public reports

• github.com/anthropics/claude-code — multiple issues on weekly reset cycles shifting days, "All models" vs "Sonnet only" diverging
• Feb 2026 prompt-caching-bugfix incident shifted users Wed → Fri on global rate-limit reset, without zeroing the counter
• HN discussions: weekly period anchors to first use after a reset, not to the end of the previous cycle — makes drift inevitable when a reset is delayed
• Late April 2026 GitHub issue: reset time changes without an actual reset event, usage not credited back

Request

1. Investigate this account's reset history. Confirm whether the Apr 21 → Apr 30 timer collapse was intentional or anomalous.
2. Document the canonical cycle-anchor mechanism — is it a fixed weekday, floating-from-first-use, or per-tier?
3. If anchor changes are expected, surface a notification in the UI so users don't perceive billing drift.
4. Ensure mid-cycle rebase events don't silently lose usage credit or shift users into a longer cycle without a corresponding limit increase.

Attachments

• anthropic-bug-2026-04-30-screenshot-A-apr21-thu-resets.jpg — Apr 21 view showing two timers with different Thursday reset times (3 PM and 9 PM)
• anthropic-bug-2026-04-30-screenshot-B-apr30-sat-resets.jpg — Apr 30 view showing both timers rebased to Sat 3 AM ET

Local alerter output (Apr 30, 2026, ~2:45 PM ET)

Week: Thu Apr 23 03:00PM ET → now

Daily breakdown:
  Thu Apr 23: $10.06
  Fri Apr 24: $61.50
  Sat Apr 25: $38.47
  Sun Apr 26: $68.08
  Mon Apr 27: $42.78
  Tue Apr 28: $41.11
  Wed Apr 29: $16.07
  Thu Apr 30: $7.19

Total: $285.27  (~285% of $100/mo Max value)
Run rate: $286.84/wk

Plan signal: Heavy use — $286.84/wk. Max is the right pick.

Reset in <15 min.

The local tracker fired its "reset in <15 min" alert at ~2:45 PM ET on Thu Apr 30 (its own anchor). Anthropic's UI at the same moment showed reset-not-until Sat May 2 at 3:00 AM ET — the divergence between the local tracker's expected reset and the UI's actual reset is itself part of the evidence.

What Should Happen?

All models would reset on the same day and time.

Error Messages/Logs

Steps to Reproduce

3 weeks same pattern.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.123 (claude code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information