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)?

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

no free reset now, only weekly

Tuesday 2 am reset in evy week

Tuesday 1 am reset in evy week

I have both ChatGPT and Claude and the weekly limits at Claude make you rather use codex. You get more work done by a long shot.