claude-code - 💡(How to fix) Fix Weekly usage reset occurred ~2 days early; displayed reset time shifted backward before triggering (Pro) [2 comments, 2 participants]

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?

The weekly usage counter reset approximately 2 days earlier than the originally displayed reset time. Before triggering, the displayed reset time shifted backward in stages over the course of the week, then the reset fired at the earlier time — forfeiting the remaining portion of the current week's allocation.

This is the inverse of the behavior documented in issue #51222 (reset times shifting forward), but produces the same functional result: a usable week shorter than the documented 7-day rolling window.

Timeline (America/Chicago, CDT):

• Initial state: Settings → Usage displayed weekly reset at Friday, 4:00 PM.
• Later observation: Displayed reset had moved to Thursday, 4:00 PM (−24h).
• Later observation: Displayed reset had moved to Wednesday, 9:00 PM (−19h further; −43h total vs. original).
• Shortly after: weekly counter actually reset at approximately Wednesday 9:00 PM — roughly 2 days earlier than the originally promised Friday 4:00 PM.

Net effect: the Wednesday-evening-through-Friday-afternoon tail of the week's allocation was forfeited without notice or credit.

What Should Happen?

Per Anthropic's own statement in issue #51222:

"Weekly limits reset on a rolling 7-day window from your first prompt, not a fixed wall-clock time, so the 'resets by …' time can shift as you keep using Claude."

Under that rule, the reset should occur no earlier than 7 days after the first prompt of the current window. If the displayed reset time must shift, it should only shift forward to reflect a later first-use anchor — never backward in a way that truncates the current week.

Expected: reset fires at or after the originally displayed Friday 4:00 PM. Displayed reset time is either stable or monotonically non-decreasing.

Error Messages/Logs

No error messages. This is a silent quota state transition observable only in Settings → Usage.

Steps to Reproduce

I am unable to deterministically reproduce this — the anchor-shift behavior appears tied to backend state that is not user-controllable. What I can provide is the observational sequence:

1. Open Settings → Usage while in an active weekly window with non-trivial usage accumulated.
2. Note the displayed "resets by" timestamp.
3. Continue normal usage across several days.
4. Re-check the displayed reset timestamp periodically.
5. Observed: timestamp shifts backward across successive observations (Fri 4PM → Thu 4PM → Wed 9PM in my case).
6. Observed: reset fires at the most recent (earlier) displayed time rather than the original.

Requesting Anthropic-side: please audit the logic that updates the weekly-window anchor and confirm whether backward shifts are possible under any condition.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

N/A — issue observed on claude.ai web interface (Pro plan), not Claude Code. Filing here because this is the active repo for weekly-limit issues (see #51222, #30933, #9424).

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Xterm

Additional Information

Related issues documenting adjacent weekly-limit anomalies:

• #51222 — displayed reset time shifts forward without actual reset (opposite direction, same net harm)
• #30933 — displayed reset time passes but quota does not refresh
• #9424 — broader weekly-limit reset anomalies, October 2025

Collectively these suggest the weekly-window anchor logic has multiple failure modes — forward-shift (steals from current week), stall (steals from new week), and now backward-shift (steals tail of current week). Requesting that Anthropic publish the anchor-update rules so users can reconcile displayed reset times with actual reset behavior.

Plan: Pro Extra usage: [FILL IN — on/off. If on, note whether any spend was incurred during the Wed-evening-to-Friday window that was forfeited.]

Attaching screenshot(s) of Settings → Usage where available.