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

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