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.
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.
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.
Instead of relying on seven_day.resets_at, detect the last drop in the utilization counter and project forward by 72 hours:
- Does it apply to all plan tiers (Pro, Max 5x, Max 20x)?
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:
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.) 🫡❤️