[BUG] Weekly "all models" counter dropping mid-cycle without reset (Max, Opus 4.7)

Preflight Checklist

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

What's Wrong?

The "Current week (all models)" counter shown in /usage is dropping
by large amounts mid-cycle without a reset event firing and without
the displayed reset timestamp being reached.

On May 15, 2026, I observed the counter at ~52% earlier in the day,
then ~5% later the same day, with "Resets May 17, 4am
America/Guatemala" displayed throughout. This has happened on
multiple days this week — the counter climbs into the 40–50% range,
then drops back to single digits without ever hitting 100% and
without the displayed reset time elapsing.

The "Current week (Sonnet only)" counter is at 0% throughout
(I primarily use Opus 4.7), so the anomaly is isolated to the
"all models" counter.

What Should Happen?

Under the documented 7-day anchored cycle, the "all models" counter
should accumulate monotonically within a cycle until either it
reaches 100% (causing a lockout) or the displayed reset timestamp
is reached.

The displayed reset timestamp should remain stable within a single
cycle, or shift forward in lockstep with new usage — it should never
be the case that the counter drops while the reset timestamp stays
put. If the reset timestamp is anchored to my first prompt of the
cycle (May 10 per Stats > Most active day → May 17 reset), then no
mid-cycle drop should be possible without a corresponding shift in
the reset anchor.

Error Messages/Logs

Steps to Reproduce

1. Use Claude Code on a Max plan with Opus 4.7 as the primary model.
2. Work normal heavy-but-not-extreme sessions over 3-5 days

(single-instance CLI, no parallel agents, no headless scripts,
no 24/7 background usage).

1. Check /usage repeatedly throughout the day.
2. Observed: "Current week (all models)" counter climbs to ~50%,

then drops to single digits within the same day. The displayed
reset timestamp does not change across the drop.

1. Not reliably reproducible on demand — appears tied to backend

cycle-anchor state that is not user-controllable.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown specific version — symptom first noticed week of May 11, 2026. No previous-version baseline captured

Claude Code Version

2.1.143 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment note: Claude Code is installed and executes on a
Debian 13 VM in a homelab Proxmox cluster. Network path:
Windows 11 → WSL2 → SSH → Debian 13 VM → claude binary
running under bash.

The Operating System field reflects where the Claude Code
process runs (Debian 13). The Terminal/Shell field reflects
the originating shell environment on the Windows client side
(WSL2), since none of the dropdown options describe a multi-hop
SSH path directly.

Related issues in the weekly-counter anomaly cluster (Feb–May 2026):

CLOSEST MATCH (currently stale):

• #29211 — Same symptom (weekly counter drops mid-cycle without

reset firing). Marked stale; was filed during the Feb 27, 2026
prompt-caching incident and never resolved.

Same model (Opus 4.7) and tier family:

• #52135 — Max 20x + Opus 4.7 weekly depletes disproportionately

Anchor-shift / early-reset family:

• #52466 — Reset fires early, quota lost
• #52498 — Anchor shifts backward, early reset
• #52921 — Weekly counter on ~24h cycle
• #54974 — Reset day drifts forward each week
• #55150 — Multiple anchor shifts in one account
• #49599 — Cycle weekday changed silently
• #58101 — Most recent (May 8); plan upgrade not applied to

weekly limit

This report differs from all of the above in that the counter
drops while the displayed reset timestamp remains unchanged.
Closest precedent is #29211, but that has not been actively
triaged since Feb 2026.

Screenshots:

<img width="1288" height="928" alt="Image" src="https://github.com/user-attachments/assets/884de842-1780-44d8-a93c-adcf6b57076c" />

<img width="1172" height="1036" alt="Image" src="https://github.com/user-attachments/assets/b2dab509-55d5-4ed1-a2af-dcedf43fb603" />