Claude Code: the 'weekly' usage limit resets every 72 hours, not 7 days

claude-weekly-reset.md

Claude Max: The "Weekly" Limit Resets Every 72 Hours, Not 7 Days

Background

Claude Pro/Max plans expose a usage API at https://claude.ai/api/oauth/usage that returns two utilization counters:

• five_hour.utilization — a rolling 5-hour window (well documented)
• seven_day.utilization — described as a "weekly" cap

The seven_day object also contains a resets_at field. Monitoring this field over ~11 days (June 9–20, 2026) revealed that the "weekly" limit does not reset every 7 days — it resets every 72 hours.

Observed Reset Events

All times are UTC. Resets detected as sharp drops in seven_day.utilization:

Reset time (UTC)	Local (CEST, UTC+2)	Weekday	Gap from previous
2026-06-10 04:25	06:25	Wednesday	—
2026-06-13 04:21	06:21	Saturday	71.9 h (3.00 days)
2026-06-16 05:00	07:00	Tuesday	72.6 h (3.03 days)
2026-06-19 05:29	07:29	Friday	72.5 h (3.02 days)
2026-06-20 04:50	06:50	Saturday	—

The 72-hour intervals are extremely consistent (±0.6 h over three consecutive cycles). Resets happen at a fixed anchor time (~04:50–05:00 UTC), not on a specific weekday.

Anthropic does not document this behavior publicly as of June 2026.

The resets_at Field Is Misleading

seven_day.resets_at consistently returned a date approximately one week in the future — always landing near Tuesday at ~07:00 local time in CEST. This is technically accurate for a 7-day rolling window (it tells you when the oldest tokens in the window drop off), but it does not predict when you get a fresh allocation.

The actual rate limit reset — when utilization drops back to near zero — follows the 72-hour cycle, not the 7-day window timestamp.

Workaround

Instead of relying on seven_day.resets_at, detect the last drop in the utilization counter and project forward by 72 hours:

Open Questions

• Does it apply to all plan tiers (Pro, Max 5x, Max 20x)?

yeah they launched a new feature were you can see your claude history, this incombination with the launch of GPT 5.6, they had too, but ths week waited longer than usual for the reset

They were too late with the reset for me I already bought a ChatGPT subscription yesterday xD

intresting my max plan resets everytime I reach 94/92/91 %. past 2 monthes, anyone else experiences this?

Mine has been resetting every Wednesday and Thursday at 4am. I’m not sure if this is going to become a regular occurrence.

same, 20x plan here, resets on thursday and sunday
bug or feature?

same, 20x plan here, resets on thursday and sunday bug or feature?

lucky duck! mine resets exactly once a week at the exact same time.

My 20x plan resets on Thursday night and Saturday morning. Strange

My pro plan resets on Thursday and Sunday

Mine used to be Wednesday (unofficial) and Monday (official) but it did not reset tonight 😭

this got too popular why people hate free stuff

Guys, any update on whether you received a reset today, since it’s Thursday?

I didnt yet.

Guys, any update on whether you received a reset today, since it’s Thursday?

Nothing for me, hoping so as im maxxed lol.

@zubeyda20166 Mine didn't reset this week. My account was resetting on Wednesdays and Saturdays, so I spent all my precious fable credits in 3 days. But this time around it didn't happen.

Looks like the party's over

I have decided to cancel my subscription and switch to OpenAI because of your untransparent rate limit policy. It is completely unacceptable that the weekly usage limit hasn't reset this week, and your interface doesn't even show the accurate time. In a highly competitive market, restricting users like this only pushes us away. OpenAI provides a much more stable and transparent experience

they stopped resetting on weekends 07/24/2026

For me too, its not resetting at thursdays anymore since 07/24/2026

@zubeyda20166 Mine didn't reset this week. My account was resetting on Wednesdays and Saturdays, so I spent all my precious fable credits in 3 days. But this time around it didn't happen.

That was their trick to "game" you into buying an upgrade or usage credits. I guess it worked for some degree, then slowed down, so they disabled this "marketing experiment".

They saw your comments, now it resets once per week. Good job :)

They saw your comments, now it resets once per week. Good job :)

I think everyone is overlooking the obvious possibility that the weekly Claude reset is not a quota issue at all, but a conservation problem involving Schrödinger’s Cat, the Token Fairy, and the Royal Egg.
The Token Fairy exists in a superposition of “reset” and “not reset” until somebody opens the usage page. At that exact moment, Morpheus observes the system, collapses the state, and steals 12% of the remaining tokens.
Meanwhile, the Royal Egg is being transported across the kingdom by William “Egg” Ellis under armed protection. Every scrum generates a localised disturbance in the quantum field, which explains why some accounts reset on Tuesday, some on Sunday, and one bloke hasn’t reset since May.
Anthropic are aware of the issue, but unfortunately the King’s men cannot patch the scheduler until the peasants stop intercepting the Egg.
Please stop refreshing the dashboard. You are changing the result.

That's great! Everyone notices early reboots, but no one notices an abnormal increase in context consumption during the same periods. There is no justice. There is an injustice.
Clearing the sandbox between moves.
An isolated environment does not require lengthy measurement and log reading procedures, and a compact counter that does not reset is sufficient.

I have a Team Plan with a Standard seat. Could you share the script for monitoring the "real" reset and token limits so I can check if that applies to my plan as well? I noticed it in the Claude Pro Plan I had before. I would need this right now, haha. 94% used and it says "reset on Saturday".

is still do the same way these days ? i have reached my limit right now

You are full of shit, my friend.

Token Fairy and William Egg Ellis aside, here’s the actually useful observation from our own Claude Code workflow.

We repeatedly saw disproportionate usage in very long-running sessions after compaction, especially when the same lane later went idle, resumed, or switched into a substantially different kind of work.

Compaction itself wasn’t consistently a problem for us. If a compacted lane stayed on the same bounded engineering task, usage could remain perfectly reasonable.

The pattern became much more noticeable when we carried that compacted session into a different work domain, or kept the same session alive through multiple compactions.

The simplest analogy I can think of is carrying your science, maths and English books around all afternoon while doing PE. The old material is still with you because it preserves continuity, but most of it is no longer relevant to what you’re doing now. In our experience, that kind of accumulated context appears to become expensive in long-lived sessions.

We eventually built a small internal observation/control-room layer that helped us track session state, recognise when a lane was getting close to compaction, and checkpoint durable state outside the conversation

The rough rule that has worked better for us is:

• same bounded task after one compaction: usually fine
• major task/domain switch after compaction: consider checkpointing and starting a fresh session
• multiple compactions in one long-lived lane: we generally restart rather than keep stacking context

Since changing the way we manage those session boundaries, our usage has been much more predictable.

Important caveat: we don’t have Anthropic’s internal telemetry, so this isn’t a claim about how their backend token accounting works. It’s simply an operational pattern we observed in our own workflow and a way of managing it that has worked better for us. Maybe it helps someone else keep a closer eye on their own sessions.

(This came out of a discussion with our internal agentic engineering team while reviewing our own Claude Code workflow.) 🫡❤️

I am not concerned with how Anthropic's services work internally or how they are integrated — that is outside the scope of my interest. I maintain a public repository of chatman scripts (/dtba3a-del/tree/main/chatman/). Their purpose is to prevent context leaks, including leaks through subagents whose context was not previously saved. To my knowledge, these scripts do not perform any tracking. That said, this is my personal assessment. The scripts alone are not sufficient to fully control the direction of the model's reasoning, and I do not claim otherwise.

…

On Tue, Sep 8, 2026 at 10:37 AM Lab_Admin_001 ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ Token Fairy and William Egg Ellis aside, here’s the actually useful observation from our own Claude Code workflow. We repeatedly saw disproportionate usage in very long-running sessions after compaction, especially when the same lane later went idle, resumed, or switched into a substantially different kind of work. Compaction itself wasn’t consistently a problem for us. If a compacted lane stayed on the same bounded engineering task, usage could remain perfectly reasonable. The pattern became much more noticeable when we carried that compacted session into a different work domain, or kept the same session alive through multiple compactions. The simplest analogy I can think of is carrying your science, maths and English books around all afternoon while doing PE. The old material is still with you because it preserves continuity, but most of it is no longer relevant to what you’re doing now. In our experience, that kind of accumulated context appears to become expensive in long-lived sessions. We eventually built a small internal observation/control-room layer that helped us track session state, recognise when a lane was getting close to compaction, and checkpoint durable state outside the conversation The rough rule that has worked better for us is: - same bounded task after one compaction: usually fine - major task/domain switch after compaction: consider checkpointing and starting a fresh session - multiple compactions in one long-lived lane: we generally restart rather than keep stacking context Since changing the way we manage those session boundaries, our usage has been much more predictable. Important caveat: we don’t have Anthropic’s internal telemetry, so this isn’t a claim about how their backend token accounting works. It’s simply an operational pattern we observed in our own workflow and a way of managing it that has worked better for us. Maybe it helps someone else keep a closer eye on their own sessions. (This came out of a discussion with our internal agentic engineering team while reviewing our own Claude Code workflow.) 🫡❤️ — Reply to this email directly, view it on GitHub <https://gist.github.com/monperrus/3ac4b303a84946bbeaf2b1123ee99491#gistcomment-6357373> or unsubscribe <https://github.com/notifications/unsubscribe-auth/BXPRGCKIKW7M3CE42PO4SVL5N6ZMNBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLKJSHE2TSNBWG43DFJDOMFWWLKDBMN2G64S7NFSIFJLWMFWHKZNEORZHKZNENZQW2ZN3ORUHEZLBMRPXAYLSORUWG2LQMFXHIX3BMN2GS5TJOR4YFJLWMFWHKZNEM5UXG5FENZQW2ZNLORUHEZLBMRPXI6LQMWWHG5LCNJSWG5C7OR4XAZNLI5UXG5CDN5WW2ZLOOSTHI33QNFRXHEMCUR2HS4DFURTWS43UUV3GC3DVMWUTCNJQGI3DOOBQGGTXI4TJM5TWK4VGMNZGKYLUMU> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

However, at the time of publishing my first message, the limits had already been exhausted. and as you can see from the screenshot, they haven't been restored yet. at the same time, something happens. in the github brunch 7 hours ago (same time interval) Claude Code activity is also recorded. Without my orders, what were the models doing? No orders were issued. The Antropic limits have been exhausted and have not been restored

Great. now delete this before Anthropic makes it longer