When does the 5-hour window actually reset?

If you have ever had a usage tracker say "2h14m to reset" while /status in Claude Code said something else entirely, you are not going mad and neither tool is necessarily broken. They are answering slightly different questions. This post explains why, and which one to believe.

I build a usage meter, so this is also a confession: getting this right is harder than it looks, and I have got it wrong twice.

The window anchors to you, not to the clock

The 5-hour session limit is not a wall-clock bucket that flips at midnight, 5am and 10am. It runs from your first message. Send one message at 09:12 and your session runs to roughly 14:12, whether you used it hard or barely touched it.

Now look at what a local tracker has to work with. It reads the log files Claude Code writes on your Mac and has to reconstruct where your session started. Most tools take the pragmatic route and group activity into fixed five-hour blocks anchored to the hour - ccusage blocks does exactly this, and it is a perfectly sensible way to summarise a day's work.

But a block boundary at 08:00 and a real session anchor at 09:12 are not the same thing, and the countdown you get from one is not the countdown you get from the other. That single hour of offset is the source of most "my tracker is lying to me" reports.

The percentage has a bigger problem than the countdown

The reset time is only half the gauge. The other half is "38% used", and that requires a denominator: how many tokens is your window worth?

Anthropic does not publish that number. Its own support documentation says exact token limits are not published, and the plan limits have moved more than once in the past year. So every tracker showing you a percentage falls into one of these:

• It read the real percentage from your account. Accurate, because it never needed a denominator.
• You typed the number in. Accurate at the moment you typed it.
• It watched you hit a wall once and measured what that took. Sounds authoritative. Usually wrong - see below.
• It shipped with a guess. Fine until your plan is not the plan the guess was tuned for.

Why "it learned my limit when I hit the wall" undercounts

This is the subtle one, and it is worth understanding before you trust any auto-calibrating gauge, mine included.

The idea is appealing: when you hit the limit, add up everything in the logs for that window, and there is your limit. Measured, not guessed.

The flaw is that the logs only contain what happened on that machine, in that tool, after you granted access. Anthropic counts Claude and Claude Code against the same pool. So if any part of that window was spent chatting on claude.ai, or on your other laptop, or before you set the tracker up, none of it is in the sum. The measurement comes out too small - and a limit that is too small makes the gauge deplete too fast, forever, because the tool now believes it has "measured" the truth.

On one real Max 5× account, that limit-hit method measured about 10 million weighted tokens where the same account's official readings implied around 25 million. Two and a half times off, latched in permanently, gauge visibly free-falling and snapping back at every refresh. That was my app, and fixing it meant accepting that a wall-hit is a lower bound, never ground truth - so a higher, better-sourced estimate has to be allowed to supersede it.

If your gauge sits at 90-something percent and lurches by several points between refreshes, this is very likely what you are looking at.

Even the official number is a few minutes old

Reading your account's real percentage solves the denominator, but it does not stream. It refreshes on the order of every few minutes. In between, a heavy agent run can move you a long way.

So a gauge that just displays the last official reading will sit there looking comfortable while a parallel refactor eats the rest of your window. The fix is to treat that reading as an anchor and subtract locally-observed usage since that instant - which only works if you know the denominator well enough for the subtraction to mean anything. Extrapolating against a guessed limit produces a gauge that lurches around, and if you have wired a budget brake to it, one that blocks real work off bad arithmetic.

That is the whole design problem in this category, and it is why MeterTab will tell you it is estimating rather than quietly presenting a confident wrong number.

Practical rules

1. Believe /status and Settings → Usage. When a tracker disagrees with those, the tracker is wrong.
2. Expect a local-only tool to undercount if you also use Claude in the browser or on another machine. It cannot see that usage. Nothing local can.
3. A lurching gauge means a bad denominator, not a bad connection. Recalibrate it from the official percentage rather than trusting a figure it inferred at a wall-hit.
4. Watch the tighter of your two windows. The 5-hour one is the one you notice; the weekly one is the one that costs you a week.
5. If a run absolutely must not blow the window, do not rely on watching it. A PreToolUse hook can stop the agent. A number on a screen cannot.

Related

• Claude Code's weekly limit, and why it catches people out
• Is Claude down, or am I out of tokens?
• MeterTab vs ccusage

Checked against Anthropic's public help centre and ccusage 20.0.19 on 3 August 2026.