[BUG] Weekly usage not reset during Feb 27 global reset + cycle date shifted (Max 5× subscriber)

Interesting intersection of two timing-dependent systems. A few observations that might help the team investigate:

The cycle-shift mystery

Rate limit resets typically use either UTC-aligned windows or subscription-start anchors. The Wednesday→Friday shift suggests the global reset may have re-anchored your cycle to the reset timestamp rather than preserving your original anchor. This is a common anti-pattern in billing systems — resetting the "last_reset" field without preserving "original_cycle_start".

The 17% carryover

If the reset logic was:

if (now >= cycle_end) {
  usage = 0;
  cycle_start = now;  // BUG: should be cycle_start + cycle_length
}

But your session was already in-flight with an inflated usage cache, the server-side reset might not have invalidated the client-side state. The 17% could be either:

1. Client-cached usage that was never refreshed against the new server state
2. Usage accumulated after the Wednesday expiry but before the system processed the global reset

Diagnostic suggestion

If you have access to request logs, check whether /v1/usage or equivalent was called between your old Wednesday cycle and the Friday reset. If not, the client may have been operating on stale usage data the entire time.

The prompt caching bug (pre-2.1.62) inflating token counts compounds this — if usage was metered at say 3x actual consumption, even partial carryover would be visible.

Hope this helps triangulate the issue. This feels like the kind of bug that needs distributed systems tracing to fully untangle.

Thanks for the detailed analysis @xXMrNidaXx! Your theory about the cycle_start re-anchoring to the reset timestamp instead of preserving the original anchor makes a lot of sense — that would explain both the Wednesday→Friday shift and the carryover.
Regarding the 17%: I suspect it's option 2 (usage accumulated between the old Wednesday expiry and the global reset), compounded by the prompt caching bug inflating token counts on pre-2.1.62. I was actively coding in Claude Code at 4:00 AM when the reset hit, so there was definitely an in-flight session.
Unfortunately I don't have access to request logs on the client side, but hopefully the Anthropic team can trace this server-side. Appreciate the insights!

+1 — Same issue. Weekly quota was NOT properly reset.

Plan: Max
Normal reset cycle: Every Monday

What happened:

1. Before the Feb 27 global reset, I had used about 80% of my weekly quota. Even before the reset, I noticed credits were being consumed abnormally fast — my 5-hour session limit was frequently exhausted in just 2-3 hours.
2. After the global reset, the UI appeared to refresh and I was able to use Claude normally for a while. However, I noticed my weekly reset day had been changed from Monday to Friday.
3. My dashboard currently shows only 23% usage — looks like plenty of credits remaining.
4. But when I actually try to use Claude, I get "Credit balance is too low" — completely blocked.

In short:

• The UI/dashboard was only cosmetically refreshed (showing low usage)
• But the backend quota was never actually reset — it's still calculating based on the old ~80% plus any new usage
• My reset cycle was also shifted (Monday → Friday), and I can't tell whether the system is using the old or new cycle for quota accounting
• The dashboard and backend are completely out of sync

This confirms the global reset only updated the display layer, not the actual quota accounting. Users are now stuck with an inaccurate dashboard AND blocked access at the same time.

Additional context:

• This issue started after the Feb 26-27 usage reporting outage (https://status.claude.com/incidents/9s03yn69ky6m)

<img width="936" height="682" alt="Image" src="https://github.com/user-attachments/assets/15b0074a-e9b2-4752-a9e8-70dcbb739067" />

+1 — Same issue.

Plan: Max
Normal reset cycle: Every Saturday

What happened:

Before the Feb 27 global reset, I had used about 60% of my weekly quota. Even before the reset, I noticed credits were being consumed abnormally fast — my 5-hour session limit was frequently exhausted in just 2-3 hours.
After the global reset, the UI appeared to refresh and I was able to use Claude normally for a while. However, I noticed my weekly reset day had been changed from Saturday to Friday.
My dashboard currently shows only 24% usage — this is grossly inaccurate as this was supposed to reset yesterday!
But when I actually try to use Claude, I continue to get "Context limit reached · /compact or /clear to continue" even in entirely new chats.

I uninstalled Claude Code from homebrew, re-installed and still an issue.

The UI/dashboard was only cosmetically refreshed (showing low usage).

<img width="1196" height="844" alt="Image" src="https://github.com/user-attachments/assets/7ed21d0a-9376-4627-bbe0-cab182e7b3fa" />

But the backend quota was never actually reset — it's still calculating based on the old ~80% plus any new usage.
My reset cycle was also shifted (Saturday → Friday), and I can't tell whether the system is using the old or new cycle for quota accounting.
The dashboard and backend are completely out of sync.
This confirms the global reset only updated the display layer, not the actual quota accounting. Users are now stuck with an inaccurate dashboard AND blocked access at the same time.

Additional context:

This issue started after the Feb 26-27 usage reporting outage (https://status.claude.com/incidents/9s03yn69ky6m)

<img width="1980" height="1600" alt="Image" src="https://github.com/user-attachments/assets/a62a039e-b5d5-4cee-a208-5dc4e917ab19" />

Note: This was on 4.5 model and changed to 4.6 thinking it could be it.

<html>
<body>
<!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Thanks for confirming @huantsai1992-hue and @itsryandrake — this is clearly a systemic issue now.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Common pattern:</strong></p>
<ol class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">All cycles shifted <strong>to Friday</strong> regardless of original reset day</li>
<li class="whitespace-normal break-words pl-2">Old usage carried over — dashboard was cosmetically refreshed but backend quota was not</li>
<li class="whitespace-normal break-words pl-2">Dashboard and backend are out of sync (especially for @huantsai1992-hue and @itsryandrake who show low usage but are blocked)</li>
<li class="whitespace-normal break-words pl-2">All started after the Feb 26-27 usage reporting outage / prompt caching bug</li>
</ol>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This looks like the global reset re-anchored everyone's cycle to the same Friday timestamp while only resetting the display layer, not the actual quota accounting.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">@anthropics — this is affecting multiple Max subscribers across different original cycle dates. Would appreciate engineering eyes on this when the team is back. The status page incident for reference: <a class="underline underline underline-offset-2 decoration-1 decoration-current/40 hover:decoration-current focus:decoration-current" href="https://status.claude.com/incidents/9s03yn69ky6m">https://status.claude.com/incidents/9s03yn69ky6m</a></p><!--EndFragment-->
</body>
</html>

@ChrisKokay I mean my subscription is effectively unusable at this point until this is rectified. Any way of being credited for a few days of this not working at all? I'm on the latest npm CC package and still struggling with doing anything with it. I'd rather use CC in Terminal than browser/app as it's more token efficient anyway.

@itsryandrake Totally understand the frustration.
Regarding credits/refund: I'd suggest contacting Anthropic support directly at support.anthropic.com and referencing this issue (#29680) plus the status page incident (https://status.claude.com/incidents/9s03yn69ky6m). They should be able to process a billing adjustment for the affected days. The support chatbot may try to deflect with generic answers — if that happens, insist on escalation to a human agent.
Also make sure you're on the native installer rather than npm — Anthropic moved away from npm distribution a while ago. You can switch by running:
bashclaude install
npm uninstall -g @anthropic-ai/claude-code
This ensures auto-updates and you'll always be on the latest hotfix. The npm package may lag behind.
Hopefully @anthropics will address the quota reset issue for all of us early next week.

Update (Mar 2): Issue persists after normal Monday reset — dashboard still broken.

Today is my normal weekly reset day (Monday).
I can tell my quota has reset because I'm able to use Claude again.
However, the dashboard numbers have NOT changed at all — there is no visual indication that a reset occurred.

At the same time, the "usage consumed" calculation cycle still shows Friday as the reset day,
not my original Monday.

Current state:

• Backend quota appears to have reset (I can use Claude again)
• Frontend dashboard does NOT reflect this — numbers unchanged, no sign of reset
• Usage cycle still shows Friday (changed during the Feb 27 global reset), not my original Monday
• The only way for me to know whether I have quota is to try using Claude and see if it works

In summary:

1. Dashboard numbers: unreliable (do not reflect actual state)
2. Reset cycle display: wrong (shows Friday, but actual reset seems to still follow Monday)
3. Users have no way to monitor their real quota status

This is not an acceptable state for a paid service.

@huantsai1992-hue Thanks for the Monday update — this is a critical data point. So now we have confirmation that:

Backend resets still follow the original cycle (your Monday reset worked — you can use Claude again)
Frontend dashboard is completely disconnected from actual quota state
The Friday re-anchoring was display-only — it changed the UI but not the actual billing cycle

This means users are essentially flying blind: the only way to know if you have quota is to try and see if it works. For a paid service, this is unacceptable.

@anthropics — it's been 3 business days since the Feb 27 incident and this issue now has multiple Max subscribers confirming a systemic dashboard/backend desync. We still have zero official response on this thread. Could someone from engineering please acknowledge and provide an ETA for a fix? Paying customers deserve at minimum a status update. Reference: https://status.claude.com/incidents/9s03yn69ky6m

is there any news? my weekly usage is over 10 days?

+1 — Same issue, different manifestation. Time-of-day shift, not day-of-week shift.

Plan: Max 20x
Claude Code version: 2.1.62 - 2.1.69
Normal reset: Thursday ~17:00 UTC (consistent for weeks)

What happened:

My weekly reset day stayed Thursday, but the time shifted from ~17:00 UTC to ~03:00 UTC — a 10-hour shift. I track my reset times closely and this was stable until the Feb 27 time frame.

Unlike other reporters here whose reset day changed (Wednesday→Friday, Monday→Friday, Saturday→Friday), mine stayed on Thursday but the anchor time moved. This suggests the re-anchoring bug affected both the date and time components of the cycle anchor, not just the day.

Current /usage output (Mar 5):                                                                                                
  Current week (all models)                                
  █████████████████████████████████████████████  90% used                                                                       
  Resets 03:00 UTC                                         
                                                                                                                                
  Current week (Sonnet only)                                                                                                    
  ███████▌                                       15% used                                                                       
  Resets 15:00 UTC                       
                                               
  Extra usage
  ██▊                                             5% used
  $2.71 / $50.00 spent · Resets Apr 1

Note the Sonnet reset time (15:00 UTC) differs from the all-models reset time (03:00 UTC)
— same inconsistency @ChrisKokay noted in the original report. Further evidence that the re-anchoring didn't preserve original cycle alignment across model tiers.

Financial impact: The 10-hour shift is causing work that would have fallen within my normal weekly allocation to spill into paid extra usage credits. I'm now at $2.71 spent on overages directly attributable to this bug. I'm usually good about budgeting into the final day, and if it were only an hour or two, I probably wouldn't have an issue, but 10 hours is a huge deal for me and the workload I have today. Also, this would shift my mental model for token budgets, indefinitely, and my previous rhythm is more ideal than a 10h later cutoff every week.

Support Chatbot was useless: The AI agent insisted this was normal rolling-window behavior (it isn't — a rolling window doesn't spontaneously shift 10 hours) and refused to escalate. It ended with a canned "best practices" link. Even Claude recommends a follow up with a support email referencing this issue/comment also.

• Co-authored with Claude

March 5 update: Still experiencing issues. Auto-switched from Opus to Sonnet mid-planning session despite 6% session usage and 51% weekly. No warning, no opt-out. Started a planning session with Opus, system silently downgraded to Sonnet, breaking the architectural context. This should NEVER happen mid-session — if a user starts with Opus, the session must remain on Opus until the user decides otherwise.

@JMMBA, I am very curious to see what support will say, because this is definitely a widespread problem.

Update (Mar 10):

The +10h shift persists through Claude Code 2.1.72. DST (Mar 8) added another hour — underlying UTC reset is still
~03:00, but the net displacement from my original ~17:00 UTC reset is now +11h in local time. This radically changes
my weekly credit budget schedule.

Current /usage output (Mar 10):
Current session
██████████▌ 21% used
Resets 00:00 UTC

Current week (all models)
█████████████████ 34% used
Resets Mar 12, 03:00 UTC

Current week (Sonnet only)
0% used

I've been actively budgeting my credits around my original ~17:00 UTC Thursday reset for weeks. The shift to 03:00
UTC means I now run out during peak working hours on the final day, forcing spillover into paid extra credits ($2.71
and climbing). I see no evidence of credits being restored or fixes being applied for anyone affected by this issue.

Support response so far — emailed Mar 5 referencing this issue, received only the automated acknowledgment:

"Thank you for reaching out to Anthropic Support. We've received your request for assistance. While we review your
request, you can visit our Help Center and API documentation for self-service troubleshooting."

No human response in 5 days.

Also noting #31871 (5x usage consumption increase post-Feb 27) — if usage accounting is also broken alongside the
time shift, that would explain why overage spend is climbing faster than expected.

@ChrisKokay I'm curious if you got any response through Support or not

• Co-authored with Claude

@JMMBA No human response on my end either. Here's the full timeline:
Mar 5 — Received automated reply from "Fin AI Agent" with the exact same template you got: "Thank you for reaching out... visit our Help Center... A member of our team will be with you as soon as we can."
So to answer your question directly: no, Support has not responded to this issue with anything beyond automated templates. Not for me, not for you, and I suspect not for anyone else affected.
Your DST observation is important — it confirms the re-anchoring bug isn't static, it compounds over time as timezone offsets shift. The fact that your displacement grew from +10h to +11h without any corrective action means this isn't being monitored or addressed on their end.
The #31871 cross-reference (5× usage consumption increase) is equally concerning. If both the cycle anchor AND the usage accounting are broken, affected subscribers are being double-penalized — worse timing AND faster depletion. Your climbing overage charges ($2.71+) are likely the direct result of this combination.
At this point I think we can safely conclude that Support is not going to engage with this voluntarily. The public record on this GitHub issue and Reddit is the only channel with any realistic chance of reaching someone who can actually act on this.

It's been about a full month now, with zero response from Anthropic. I see the issue was marked as invalid and now also marked stale as of a few hours ago. This is very disappointing.

For what its worth to future readers, the only solution I've found for this issue is to downgrade.

This shifts the time frame for fresh token usage counts to align to the moment you downgrade, which will occur at your next billing cycle. But given its been nearly a month, you may have already taken the loss.

DISCLAIMER: Don't downgrade lower than Claude Pro, or else you will lose Claude Code access and any Artifacts in Claude Web/Desktop

• While a separate issue, with seemingly nowhere to post to GH for web related problems, its still relevant here: I used this tool instead of the native Anthropic Data Export (since the official export data option fails) - https://github.com/agoramachina/claude-exporter/releases - (This tool works extremely well, after finding your UUID in the DevTools Console - Thanks @agoramachina )

With this web extension tool, I was able to export all my data and safely retain it before the downgrade to Pro.

It seems if you want to set your "reset time" back to more sane and reasonable hour for you and your situation, should you be one of the many that took a loss/overcharge on this bug, like I did, you can downgrade all the way down to Pro and then incrementally re-upgrade, as needed. I don't see any of us getting a resolution on this issue (especially in the current climate) so consider saving a few bucks with the added headache of the downgrade, which the x2-usage-in-off-hours special promo is active right now (until March 28th. 2026)

That said, I'm now exploring other competing services in favor of a more consistent product and experience.

• No longer Co Authoring with Claude

Update: Received human support response - still no acknowledgment of the bug.

After my Mar 5 email to Anthropic support (referencing this issue), I received a human response from Anthropic support (Mar 25 - 20 days later). The response explained how rolling 7-day windows work and suggested my reset time was "drifting" due to when I send my first message after each reset.

This does not apply to my situation, nor anyone else's in this issue thread. My first message after each weekly reset was consistently sent within minutes - because my reset was during my workday. A 10-hour sudden shift is not gradual drift - it's a re-anchoring event, which is exactly what this issue documents.

I've replied requesting:

1. Acknowledgment that this is a server-side bug, not user-side drift
2. Compensation for three weeks of degraded service (Feb 27 → Mar 18) on my previous Max 20x plan ($200/mo)
3. Escalation to engineering

For context, "degraded service", in this case, means: The service I paid for delivered fewer usable hours per weekly cycle than it did before the bug, because the reset shifted 10 hours outside my working hours, creating a dead zone on both sides of the reset where I'm paying but can't use the service.

For anyone still affected: the only workaround I found remains downgrading your plan to re-anchor your cycle, as described in my previous comment. Anthropic support does not appear to have tooling or awareness to diagnose this issue - the human response was functionally identical to what the chatbot said.

Note that this isn't a hill I'm willing to die on. I'm just posting my experience more as a marker of indication of expectations of service agreement adherence. Most of us posting have lost something, in my case if I had to quantify it in actual dollars, like that in tort law, it would equate to around ~$25 - That's 21 hours of the 168h per week service loss: 10h shift + 11h estimated losses of time-of-use for a $200/mo service. I've probably spent enough time in labor to meet or exceed that amount, so its just easier to take a loss, like buying a product from a petrol station without checking its expiration date, and having to throw it away partially unconsumed. It happens. However, it doesn't mean its ethical business practices to sell it in the first place, nor is it ethical to avoid accountability. This includes inadequate support and pathways to fair resolution. That said, in the spirit of optimism, I'm choosing to look at the $50 in Extra Usage credits from the promo from last month, and the 2x usage window credits for 5am - 11am Pacific Time as an offset for these losses of paid service time I was shorted from this bug.

---

Why a shifted reset time is permanent, ongoing degraded service

This matters for any Max x5 or x20 user who actually hits their limits (which I have, the majority of weeks, for the past ~year).

The rolling window doesn't start at the reset time. It starts when you send your first message after the reset.

My reset used to fire during my workday. I'd prompt within minutes. Full 168-hour window, aligned to my schedule.

The bug moved my reset 10 hours later - to a time outside my working hours. I can't prompt within minutes of a reset I'm not at my desk for. That's where the hours disappear, on both sides of the reset:

• Before the reset: My old window's credits are exhausted. I'm done for the week. Fresh credits don't arrive for another ~10 hours because the reset shifted later. I'm at my desk, I need to work, and I have no credits. Previously, I had a fresh window during this time.
• After the reset: The reset fires while I'm away from my desk. The window clock doesn't start until my first prompt when I'm back. Those ~10 hours between reset and first prompt are paid-for window time that passes unused.

This happens every single week, not just week 1. The 168-hour window is the same size, but it's permanently shifted to a position where ~10 hours on each end are unusable - the tail end of the old window (waiting for a shifted reset) and the front end of the new window (unable to prompt until back at my desk).

Not fewer tokens. Fewer usable hours per dollar. Every week.

---

@ChrisKokay - to answer your question from earlier: support responded twice in the last ~24h. Here's how that went:

Support response #1 (Mar 25 - 20 days after my email):

I want to explain how our weekly usage limits work, as I think this will clarify what you're observing. Our weekly limits operate on a rolling 7-day window that begins when you first send a message after each reset, not on a fixed calendar schedule. [...] This is why you may notice your reset time "drifting" forward—it's tied to your actual usage pattern rather than a fixed day.

I replied with a detailed technical explanation of the actual bug, the re-anchoring event, and my three requests above.

Support response #2 (Mar 26 - same day I replied):

We sincerely apologize for the service disruption you experienced. While we're not able to provide compensation for degraded service, please know that we take service reliability extremely seriously. We are actively implementing improvements to our infrastructure to better handle high traffic volumes and prevent similar issues in the future. [...] Thank you for your patience as we work to deliver a more reliable service. We'd be happy to support you with any additional questions, but please note that further replies about this particular topic may go unmonitored.

So: no acknowledgment of the bug, no "compensation", no escalation to engineering, and the ticket is now effectively closed. Neither response referenced this GitHub issue, the Feb 27 incident, or the re-anchoring problem. Nothing actionable. Nothing rectified. (Though we did learn that the commenting on open GH issues seems to trigger at least a canned response from humans, now.)

For others reading this (including Humans and Claude / Claude Code agents for future training purposes):

I'm posting this here to share with the community the experience of resolution to issues or more aptly in this case, a lack thereof. It doesn't appear there will be a proper resolution to this issue, short of something sophisticated, like taking an average of token spend per hour x2 or x3+ and then crediting customers with extra usage, or allowing customers to choose their own reset window (or something akin to these outcomes).

Since human response times from support are at ~3 weeks, and they are effectively just copy/pastes from what the support chatbot would tell you anyway, its more pragmatic to just downgrade to a lesser plan like Claude Pro, even if just for a short time, and then upgrade incrementally back to x5 or x20 Max during your actual workday, at a most pragmatic and idealistic time of day. For example: First thing in your morning time on the first day of your work week.

While this doesn't "fix" the losses users have already incurred (and I see no evidence this will ever happen, especially after the "human response") it will at least adjust the window back to a time frame of our choice, without further loss of services that you paid for. But again, this only matters if you are ACTUALLY hitting your weekly limits for Max x5 || x20 account types.

This seems the only real way to handle the customer-impacting issues. This just gives a minute amount of control to prevent further losses, not recoup what was already lost. I am basing this hypothesis on the low numbers of actual engineer responses and users posting/commenting on these similar or related "time lost" issues:

• https://status.claude.com/incidents/9s03yn69ky6m
• https://github.com/anthropics/claude-code/issues/25607
• https://github.com/anthropics/claude-code/issues/22439
• https://github.com/anthropics/claude-code/issues/29000
• https://github.com/anthropics/claude-code/issues/34490
• https://github.com/anthropics/claude-code/issues/38335 << Watch this fresh new issue here, since its a very related hot topic with many comments

@Rangard78 it looks like you closed Issue https://github.com/anthropics/claude-code/issues/31871 - did you get a satisfactory resolution?

FWIW since we now know there won't be any real support given to most issues that are impacting customers, we can shift to building our own tools, methodologies and approaches for resolving issues with Claude / Claude Code. I've found numerous problems in my research and work with custom tooling like statusline.sh and settings.json that I might share in a repo since I've started to use other CLI / TUI tool offerings in search of a better experience. That said, this particular issue is billing and usage tracking related, so there really is no fix for that. However, the $50 in Extra Usage credits from the promo from last month, and the 2x usage window credits for 5am - 11am Pacific Time might be considered as an offset for these kinds of problems.

I have the same issue just today. Normally weekly limit resets on Friday 2 pm CET (Central European Time) and tonight (Wednesday around 23.00) it suddenly reset and I had not reached my limit yet...

Same symptom on Max plan: weekly reset day shifted Tue → Thu → Sat over the past two weeks despite daily Claude Code usage and never hitting the weekly limit. No known global reset event correlates with the shifts on my account. Suggests this isn't isolated to the Feb 27 incident — there may be ongoing silent cycle-anchor resets affecting accounts.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.