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

Solid empirical catch on the resets_at decoupling. What you’re observing is the classic gap between a passive sliding window tail (which tracks when the oldest timestamped tokens fall out of the seven_day ledger) and an active fixed-window sweep (the backend cron hard-flushing the utilization counter).

However, a quick word of caution from an SRE/automation standpoint regarding the proposed workaround (project forward by 72 hours): treating a black-box scheduler as a deterministic constant is a high-risk footgun for long-running agentic loops.

As @imoreiranut-beep pointed out, the cycle length already drifts across tier brackets (Pro vs. Max 5x vs. Max 20x). If upstream migrates this ledger to a continuous Leaky/Token Bucket with linear decay, or simply shifts their cron anchor time, any client-side orchestrator hardcoding t_drop + 72h will silently stall or throw 429 Too Many Requests right in the middle of a hot state.

Rather than trying to predict the gateway's flush cycle at the transport layer (Layer 3), the safer architectural pattern for heavy workloads is demand reduction at the orchestration layer (Layer 2):

1. Local AST & State Caching: Deduplicating deterministic tool outputs and file reads locally before they ever hit the wire.
2. Payload Density: Serializing structured context (JSON-only deltas) instead of passing raw conversational history back and forth.

When you shrink your average outbound token payload by ~60–70% locally, whether upstream resets their sliding window in 72 hours or 168 hours becomes an implementation detail you no longer have to monitor.

Great reverse-engineering regardless; appreciate the data point.

Claude Code has double usage til July 15th, wouldnt that be what this is?

For the last two weeks, up until June 21, Claude used to reset tokens on weekends. However, Claude didn't reset them this weekend. :(
27th June