/usage weekly bar dropped ~88% → 3% after a usage-credit purchase, reset date unchanged

Summary

The /usage "Current week (all models)" indicator dropped from ~88% used to 3% used within the same day, with the reset date unchanged (so no weekly reset occurred). The drop coincided with a manual usage-credit purchase. Usage credits are a separate overflow pool and should not move the subscription weekly bar.

Environment

• Claude Code, macOS (Darwin 25.5.0)
• Team plan, personal billing, timezone Europe/Zurich
• Auto-reload: OFF (purchase was manual)

What happened

• Morning, Jun 1 2026: Current week (all models) read ~88% used.
• Afternoon, Jun 1 2026 (screenshotted): same bar reads 3% used; Current week (Sonnet only) reads 2% used.
• Reset date unchanged across both reads: "Resets Jun 3 at 2am (Europe/Zurich)" — i.e. still the same weekly window, no reset.
• Immediately prior, a manual usage-credit purchase posted: $216.20 incl. 8.1% Swiss VAT ($200 credits). Credit balance afterward: $250.

Why this looks like a bug

1. Usage credits are a separate pool ("Buy usage credits so your team can keep using Claude if they hit a limit") — overflow that engages after the subscription cap. They should not change the subscription weekly-usage percentage.
2. A decrease with an unchanged reset date cannot result from normal accrual. Usage only goes up within a window; only a reset (date rolls forward) should lower it.
3. 3% is inconsistent with documented same-day usage. The /usage Session panel reported $207.82 spent this session (≈$205 of it Claude Opus 4.8: 254.1k input, 939.5k output, 304.5m cache read, 4.6m cache write). Independent corroboration from local git history for the same day: 16 commits, +1,752 / −412 lines, sustained 20:00–21:34 local. A single session at ~$207 of mostly-Opus usage reading as 3% of a weekly cap implies a ~$6.9k/week allowance, which does not match Team weekly limits.

Expected behavior

The subscription weekly-usage percentage should be unaffected by usage-credit purchases. Only a weekly reset (reset date advances) should lower it.

Suspected cause

Client-side /usage estimator either (a) folding the credit balance into the subscription denominator, or (b) de-syncing after the purchase reconcile. The panel self-labels "Approximate, based on local sessions on this machine," so the local estimate may have diverged from server state.

Caveat / honesty note

There is no before-screenshot of the ~88% reading; that figure is from the reporter's recollection. The 3% / 2% values, the unchanged reset date, the credit purchase, and the same-day usage volume are all documented.

Repro (suspected)

1. Be near the subscription weekly limit (high % used).
2. Manually purchase usage credits.
3. Observe whether /usage "Current week (all models)" drops despite the reset date not advancing.