Weekly usage counter dropped 60% → 2% mid-cycle while resets_at still in future

Summary

On 2026-04-23 my weekly usage counter on claude.ai/settings/usage (and the matching /api/organizations/{orgId}/usage endpoint) dropped from ~60% to 2% in the middle of the week, even though the same endpoint reports seven_day.resets_at ~9 hours in the future. Both the Anthropic-hosted settings page and the raw API agree on the 2% figure, so this is not a client-side parsing or caching bug.

Environment

• Date / time of observation: 2026-04-23, 20:00–21:02 IDT (UTC+3)
• Account surface: claude.ai/settings/usage (screenshot confirms "2% used — resets in 8h 55m")
• API endpoint: GET https://claude.ai/api/organizations/{orgId}/usage
• Plan: Claude Max (weekly limit enabled)

Timeline (my local observations)

| Local time (IDT) | seven_day.utilization (from API) |
|-----------------:|-----------------------------------:|
| 13:00 | 60% |
| 14:00 – 19:00 | (no polls in this window) |
| 20:01 | 0% |
| 20:35 | 1% |
| 21:00 | 2% |

The drop happened somewhere in the 13:00–20:00 window. By 20:01 the counter was already effectively reset; it has rebuilt to 2% from minor use between 20:00 and 21:00.

The reset-time mismatch

At 21:02 IDT the API returned:

"seven_day": {
  "utilization": 2,
  "resets_at": "2026-04-24T03:00:00.264681+00:00"
}

2026-04-24T03:00:00 UTC = Fri 2026-04-24, 06:00 IDT — still ~9 hours in the future when I observed the reset. claude.ai/settings/usage shows the same — "Resets in 8 hr 55 min". So a natural weekly reset should not have fired yet, and yet the counter has already dropped as if one had.

Expected vs. actual

• Expected: utilization stays at or above ~60% until the announced resets_at, then drops.
• Actual: utilization fell to 0% roughly 9 hours before the announced resets_at; resets_at itself did not move forward to reflect a cycle boundary crossing.

Ruled-out explanations on my side

• Not a client caching issue — claude.ai/settings/usage (Anthropic-hosted) shows the same 2%.
• Not sub-second jitter in resets_at being misread as a cycle change — our recorder compares epoch-ms and only treats a ≥24h forward jump as a real reset. The stored currentResetsAt did not change during the drop.
• Not an org/session switch pulling data from a different account — the active lastActiveOrg cookie and organization_uuid in the payload are unchanged across the interval.
• Not a "defaulted payload" fingerprint (both buckets 0% with past resets_at) — the post-drop payload has a valid future resets_at and the 5-hour bucket is non-zero (8%).

Questions

1. Is the weekly limit actually a fixed 7-day cycle anchored to resets_at, or a rolling 168-hour window where resets_at is approximate / UX-only?
2. If it's a fixed cycle, how can utilization reset mid-cycle without resets_at advancing?
3. If it's a rolling window, what counts as "resets in 8 hr 55 min" on the settings page — the next scheduled boundary check, or something else?

Happy to share logs / timestamps keyed to my account if useful.