[Bug] Weekly usage limit reset occurring before scheduled reset time & new week ends in 5 days, not 7 days

Open 💬 22 comments Opened Apr 23, 2026 by mobileskyfi

Bug Description
My week limit should have ended at Thursday at 2pm local today, confirmed in claude.ai and /usage many times. I had a lot left on the weekly limit, that I was going to use today. But I just noticed that my weekly end date switched to Monday, which is not next Thursday at 2pm - which might have made sense of it was a TZ issue. I get how a week started on first prompt, but that's not what's happening here. I was actively working before the Thursday 2pm deadline for the week limit, and then now all of sudden in a new week, with different end date. So if I rolled over to a new week, that should have tripped a new 7 days, not 5 days, since the new end of week in Monday (today is Thursday). /usage is reporting the week end on Monday, in 5 days... But easily today both certainly said Thursday 2pm as they have all week.

Environment Info

  • Platform: darwin
  • Terminal: vscode
  • Version: 2.1.118
  • Feedback ID: a3b41291-59e5-445f-add4-ad5c892688db

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/amm0/.local/share/claude/versions/2.1.118 (expected in multi-process scenarios)\n    at ti6 (/$bunfs/root/src/entrypoints/cli.js:2756:2177)\n    at bq8 (/$bunfs/root/src/entrypoints/cli.js:2756:1257)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-23T12:56:33.057Z"},{"error":"Error: Plugin MCP server error - mcp-config-invalid: MCP server postman invalid: Missing environment variables: POSTMAN_API_KEY\n    at oPH (/$bunfs/root/src/entrypoints/cli.js:2756:30635)\n    at async T (/$bunfs/root/src/entrypoints/cli.js:6144:11019)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-23T12:56:34.232Z"},{"error":"Error: Plugin MCP server error - mcp-config-invalid: MCP server postman invalid: Missing environment variables: POSTMAN_API_KEY\n    at oPH (/$bunfs/root/src/entrypoints/cli.js:2756:30635)\n    at async Z (/$bunfs/root/src/entrypoints/cli.js:6144:11825)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-04-23T12:56:34.244Z"}]

View original on GitHub ↗

22 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/52466
  2. https://github.com/anthropics/claude-code/issues/49616
  3. https://github.com/anthropics/claude-code/issues/49536

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

mobileskyfi · 2 months ago

It not clear which is the parent bug, or if this is a confirmed bug. Or just a bunch of users not understand a policy change or T&C changes. The Claude Code docs are suggest are a bit vague, but 7 days is a week. And even some TZ issue does not explain a "weekly rollover" becoming 5 days. Be okay to close if there was a link to the issue that's tracking the "main" bug... but self-referential duplicated bug reports is not a solution.

WhatcomSci · 2 months ago

yeah i've had the usage date reset randomly on my several times. Again today it was set for 1pm today, I even screen shotted it to show a friend (ran through my full usage, seems like the usage was majorly nerfed). Only to see 5 minutes later now my usage is set to for Friday at 4pm. Which ok I get to start working again now.... except now the usages is being eaten up at a rate that is impossibly fast.

mobileskyfi · 2 months ago
i've had the usage date reset randomly on my several times.

This was the 2nd week where it shifted. It was always Sunday/Monday, based on the documented "week started on first prompt, after last week expired"... so I get it "floats" and some TZ shifting might explain ~1-24 hour shift (maybe, but that should be right).

In my case, I use Claude Code as a "third eye" on other agents since it has a semi-independent CLAUDE.md scheme. So I kinda plan around doing these toward the "end of the _Claude_ week"... so when it shift from Sunday -> Thursday last week, I planned around Thursday, still had ~7 hours left in week when it moved to Monday. So I was already going to leave some credits "on the table" since I had a good bit left for the week.

It was second time this has shifted that prompted the report. One I could chalk up to a one-off bug. But this really should be way more stable and predictable. The current scheme is vague on usage which is a fair enough (could quibble like any consumer) but the "conversion" part is more complex issue. Now what defines a week, should not be vague. And Claude docs explain clearly the weekly scheme.

focusonthepresent-cyber · 2 months ago

Seeing the same issue.

Plan: Pro
Date noticed: April 23, 2026
Timezone: Eastern (UTC-4)

Weekly reset date shifted from Sunday to Thursday at 10:00 AM ET, with no apparent trigger. The change did not correspond to a 7-day roll from recent activity. The date changed unexpectedly and without notification.

mister-ennui · 2 months ago

+1 — reproducing on Pro plan desktop
app version: Claude 1.3883.0 (93ff6c)
Model: Claude Sonnet 4.6
MacOS 26.4.1
Build date: 2026-04-21

My case:

  • was supposed to reset today (Thurs) at 12:00 pm
  • was at 90% weekly before that so was trying to use up before 12:00 pm
  • at 12:00 pm went to check usage - now says "Resets Tuesday at 7:00 am"
  • I'm happy that I'll reset in 5 days, but its still wrong
beyondpower-code · 2 months ago

same here Thursday to Monday

geekmdtravis · 2 months ago

Same here. I was at about 30% usage with a reset on Monday 5/27 at 10AM (approx) and it changed to 5% usage and a reset on Saturday 5/25.

Noted on web app, but FWIW.

Local: Claude Code v 2.1.119 on the following system.

<img width="1533" height="949" alt="Image" src="https://github.com/user-attachments/assets/0ea3dc93-0103-4f7b-8d8c-1bd6d32e691f" />

judahsassistant-jarvis · 2 months ago

Seeing a variant of this on Claude Max (UK). My previous weekly window was set to reset Thursday at 20:00, and it did reset on schedule. The new window that opened is now showing a reset of the following Tuesday at 14:00 — roughly 4 days 18 hours later, not 7 days. That doesn't fit the 'rolling 7-day window from first prompt' model either, since first prompt in the new cycle was after Thursday 20:00, which should put the next reset around Thursday the week after — not the preceding Tuesday. Happy to share screenshots or account details via support if useful.

TorulfMoll · 2 months ago

I have two main issues - Claude is now eating into my 5hr limit quite fast, after 10 min of light use it is at 23%. Also, the weekly allowance was reset earlier than scheduled. I had ca 14% left, due to be reset in ca 15 hours, but it was just reset now - at the very same time that i notice the depletion problem on the 5hour allowance. Im situated in Norway and on A claude pro plan

dondetir · 2 months ago

Reproducing on both claude.ai web and Claude Code CLI on Linux.

  • Plan: Max
  • Weekly limit restarted Apr 23, then showed "Resets in 10 hr 51 min" the next day (~35-hour "week")
  • Usage was only 2% at time of observation (both surfaces showed same reset time)
  • Platform: Linux, confirmed via both claude.ai web UI and /usage in Claude Code CLI

This confirms the bug is cross-platform (not macOS-specific) and cross-surface (both web and CLI affected simultaneously, as expected since they share the same limit pool).

mobileskyfi · 2 months ago

It's like Anthropic's own agents do not have some basic instruction like "if you change pricing calculations => update website with details".

Cetrateam · 2 months ago

Adding my case to support this report (Claude Pro, macOS, Italy).

Before hitting the limit, my reset date was showing as Tuesday. Once the weekly limit was fully exhausted, the date shifted forward by 3 days to Friday — without any actual reset happening and without any usage being credited back.

I waited until Friday and the limit did reset as shown. But after starting a new session, the next reset is now displaying as Tuesday again — which is only 4 days away, not 7.

So the pattern I observed: limit exhausted → reset date jumps forward arbitrarily → after the reset, the new window is shorter than 7 days. Neither the shift nor the shortened interval matches any documented behavior.

babyfings · 2 months ago

Same symptom on my account.

  • Plan: Max 5x
  • OS: Windows
  • Claude Code CLI: 2.1.119
  • VS Code extension (anthropic.claude-code): 2.1.120
  • Timezone: KST (Asia/Seoul)

A weekly reset occurred on Friday Apr 24, 2026. As of Sunday Apr 26, /usage shows the next reset as Monday Apr 27, 8:00 AM KST — about 3 days after the prior reset, not 7. Both the "All models" and "Sonnet-only" weekly buckets show the same Monday 8 AM reset time.

Current /usage snapshot:

  • Weekly (All models): 45% used, resets Mon 8:00 AM KST
  • Weekly (Sonnet only): 38% used, resets Mon 8:00 AM KST
  • Current 5h session: 22% used

Both CLI and extension are post-2.1.118, so the prompt-caching bug is ruled out.

Secondary observation: weekly usage consumed unusually fast during this cycle. No precise measurements, but the pace was noticeably off compared to prior weeks. Possibly a downstream effect of the shortened reset window itself.

YigitYerlitas · 2 months ago

Same behavior on my Max plan account. Filing my data points
here per the duplicate notice on my closed issue #54974:

  • Week 1 (initial subscription): reset Wednesday
  • Week 2: reset Thursday
  • Week 3 (2026-04-30): Usage page shows next reset Friday
  • Net forward shift: +2 days over 2 weeks

Anthropic Fin support (Conversation ID 215474123652090)
acknowledged in writing: "the math doesn't add up with a
pure 168-hour rolling window" and "your observation about
the forward shift being mathematically impossible is spot-on."

Adding this to strengthen the existing report.

saadings · 2 months ago

I am having the same issue as of Monday now. My weekly reset window was set at friday, but switched to wednesday randomly and after that I have been enduring low 5 hour session limits, before I would run into this limit occasionally but now I can pretty easily run into them in 20 mins or so.

discreteds · 2 months ago

I have an even better suggestion. We should be able to select the ideal weekly quota reset time for ourselves:

Feature Request: User-Configurable Weekly Usage Reset Anchor

Summary
Please allow paid plan users to set a fixed weekly reset anchor on a preferred day and time for their usage limit to reset, rather than the current rolling 7-day window.

Current behaviour
The weekly usage limit resets on a rolling 7-day window from first use. There is no way to configure when this will fall other than not using the service for several days. My reset currently lands at 3pm on Wednesday, the absolute peak of my work week!

Impact
This has real work-capacity and quality-of-life consequences:

  • Usage runs low from Tuesday to mid-Wednesday, disrupting the core of my work week
  • I am forced to restructure my schedule around an arbitrary and opaque reset time.

Proposed solution
Allow users to set a weekly reset anchor once (e.g. Monday 8am in their local timezone). This would:

  • Align quota availability with natural work weeks
  • Structurally encourage users to rest on weekends when quota is low, rather than mid-week or arbitrary times.
JPEG111 · 2 months ago

Exact same weekly quota reset bug confirmed with fresh screenshot (May 16, 2026)

This is the identical issue reported in this thread.
Exact timeline of what happened:

Earlier today (Saturday, May 16 2026) I checked Settings > Usage while my weekly “All models” quota was at 42% used. The UI clearly displayed that the weekly bucket would reset on Sunday.
Roughly one hour later the quota reset anyway on Saturday the remaining ~58% was permanently lost.
I then sent my first message of the new weekly cycle (still Saturday, ~1 hour ago).
Immediately after that message, Settings > Usage updated to 2% used but now shows “Resets in 23 hr 45 min”.

<img width="1041" height="387" alt="Image" src="https://github.com/user-attachments/assets/c56cc792-ba0d-4165-a30f-91520c00ea74" />

This is not the documented rolling 7-day system. The weekly limit is supposed to reset exactly 7 days from the first prompt of the cycle, not ~24 hours later. Both the display and the underlying calculation are clearly broken.
Additional evidence:

Full conversation with Fin AI Agent: Conversation ID 215474326296357 (Fin repeatedly admitted “this doesn’t match the expected rolling 7-day system” and “definitely needs investigation” but refused to escalate).
I have already emailed [support@anthropic.com](mailto:support@anthropic.com) with the same details and screenshot.

This bug has been reported multiple times since April 2026 and is still occurring. The weekly quota system is not functioning as documented, causing real loss of paid usage.

Anthropic engineering team this requires immediate investigation of my account’s quota timing and reset history. The display and calculation logic for the rolling 7-day period is fundamentally broken.

I am available to provide any additional logs, exact timestamps, or further screenshots.

This must be fixed.

leifclaesson · 1 month ago

Same bug here on Max (20x). I filed it separately as #64913 before the dedup flagged this one -- consolidating my data here instead.

Timeline

  • /usage stated both weekly pools reset "Sat 5:00 AM" (screenshots below).
  • Mon Jun 1, night: "All models" weekly meter ~67% used; countdown "4 days until reset" (consistent with Saturday).
  • Tue Jun 2, morning: same meter at 0% -- it had reset overnight, ~4 days before the stated Saturday boundary.
  • The countdown never registered the reset. As of Wed Jun 3 the popup still shows ~2 days and /usage still says "Resets Sat 5:00 AM" -- the displayed schedule never accounted for the Tuesday reset.

I'd barely used Claude over the weekend, so this was the weekly pool resetting, not a 5-hour session window. This was my first weekly reset (signed up for Max a few days earlier), so it isn't anchor drift accumulating over weeks -- the very first reset fired ~4 days early against the exact time /usage showed.

Env: Claude Code 2.1.143, Windows 11, UTC+7.

Screenshots (both captured Wed Jun 3, same moment):

/usage panel -- both weekly pools = "Resets Sat 5:00 AM", Max (20x). The "All models" bar at 29% is the meter re-accumulating after Tuesday's reset:

<img width="1474" height="844" alt="usage panel showing Resets Sat 5:00 AM" src="https://github.com/user-attachments/assets/d933b584-d02a-4087-af16-63ddb82d5662" />

Compact popup at the same moment -- weekly shows "resets 2d", so the two surfaces don't even agree (2d is Friday, vs the panel's Saturday), and neither reflects a freshly-reset ~7-day window from Tuesday:

<img width="729" height="264" alt="compact usage popup showing resets 2d" src="https://github.com/user-attachments/assets/b8e1372a-de1a-4037-b593-63746bbc3c8b" />

leifclaesson · 1 month ago

Any progress on this? My weekly usage bar is pushing ever upwards, and if it was truthful it'd be fine, but I know that in 22 hours it's going to say "reset in 7 days" or maybe 6, but the bar will _not_ have reset, and will be getting close to full by then.

<img width="737" height="359" alt="Image" src="https://github.com/user-attachments/assets/5cee08aa-2cea-45e7-b9bd-f9dbb639df48" />

This bug which seems to affect a lot of people has been open since April 24th and nobody has been assigned yet, and there's no evidence that anyone from Anthropic (or even an agent, you'd think they'd have one!) has even looked. Can we escalate this somehow?

leifclaesson · 1 month ago

BUG MAY BE FIXED.

<img width="737" height="359" alt="Image" src="https://github.com/user-attachments/assets/9e73f66f-ee0d-4012-82a9-57d8bbc59df7" />

<img width="731" height="356" alt="Image" src="https://github.com/user-attachments/assets/df5c8cdc-7176-40e6-8195-a675dcadbe6a" />

<img width="740" height="360" alt="Image" src="https://github.com/user-attachments/assets/2f168437-066b-420c-a518-0c08252b0c65" />

<img width="732" height="353" alt="Image" src="https://github.com/user-attachments/assets/36681af9-f5e3-4694-bca5-3b3a04670957" />

Stay tuned. It reset _perfectly_ this time.

leifclaesson · 1 month ago

It just reset for me again. It's wednesday morning and I'm at 0% weekly usage. So, i'm getting bi-weekly resets. I surely _do not mind_ that, that's fantastic value on an already incredible, _life-changing_ product. Just thought I'd post it here since it's relevant, even though by doing so I am by definition looking the gift horse in the mouth.

<img width="724" height="350" alt="Image" src="https://github.com/user-attachments/assets/52b4a846-3dbd-4817-9fcd-6f9bd06f7b3f" />