[BUG] A 13 hour 5-hour limit issue

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The plan usage panel shows a reset countdown for the 5-hour session limit that is longer than the window itself.

<img width="989" height="773" alt="Image" src="https://github.com/user-attachments/assets/dd8def88-7393-4885-a15f-dd91ae902206" />

A 5-hour rolling session window cannot have a countdown of 13h 37m. The value is out of range by definition.

Likely cause: the "5-hour limit" row appears to be anchored to the same daily/weekly 1:00 AM boundary used by the weekly meters, instead of to the end of the current rolling session. Counting 13h 37m backwards from 1:00 AM lands at approximately 11:23 local time, which matches when the screenshot was taken. The two weekly rows also reset at 1:00 AM, which supports the shared-anchor hypothesis.

Impact: the usage panel cannot be trusted for session planning. A user seeing "13 hr 37 min" on a paid plan reasonably concludes they are locked out for the rest of the day, when the meter shows only 13% consumed and access is in fact available.

What Should Happen?

The "5-hour limit" row should display the time remaining until the end of the current rolling 5-hour session window. That value must never exceed 5:00.

If no session is currently active, the row should show no countdown (or "—") rather than falling back to the weekly reset anchor.

Error Messages/Logs

Steps to Reproduce

1. Be on a Max (5x) plan with an active rolling 5-hour session (some usage already consumed — in my case 13%).
2. Open the plan usage panel (/usage in Claude Code, or the usage section in the client UI).
3. Read the countdown in the "5-hour limit" row.

Result: the row displays "Resets in 13 hr 37 min" — a value that exceeds the length of the 5-hour window itself.

At the same moment, both weekly rows show "Resets Sun 1:00 AM". Counting 13h 37m forward from the observation time lands exactly on the same 1:00 AM boundary, which suggests the 5-hour row is being computed against the weekly/daily reset anchor rather than against the end of the current session window.

Note: this reproduces on the account state shown in the attached screenshot. I have not tested whether the offset varies with time of day — if the hypothesis is correct, the displayed value should always equal "time until next 1:00 AM" rather than "time until session end".

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.26832.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_