[Bug] Rate limit reset countdown truncates to floor(hours) — "3h" shown when 3h56m remain
Summary
The Claude Code usage overlay (and Desktop App popover) displays the rate limit reset time as a whole-hour count using floor division. "Resets 3h" is shown when the actual time remaining is 3 hours 56 minutes — hiding 56 minutes, nearly 19% of the 5-hour window, from the display.
This is not rounding. It is truncation. The server already has the correct value.
Evidence
The two displays are captured simultaneously. The server-side value is "3 hr 56 min" (visible at claude.ai/settings/usage). The Claude Code overlay renders it as "3h".
Steps to observe
- Open Claude Code when a rate limit reset is upcoming.
- Note the displayed time in the status overlay — e.g. "resets 3h".
- Open claude.ai/settings/usage in a browser.
- The settings page shows the full precision (e.g. "3 hr 56 min"), confirming the exact value is available server-side.
Impact
A user who sees "resets 3h" and waits 3 hours will find the window has not reset. The display is systematically low by up to 59 minutes. Planning a final task before a reset based on the overlay will frequently result in hitting the limit mid-execution.
The claude.ai settings page already renders the minute component correctly. This is a presentation-layer discrepancy, not a data availability problem — the fix is one format string.
Prior report
Previously reported as #55722 (closed stale, never fixed). That report independently reproduced the same truncation in Japanese locale using the Desktop App popover. This report adds: (a) simultaneous screenshot comparison confirming the server has the precise value, (b) CLI overlay reproduction on macOS, (c) quantification that up to 59 minutes of a 5-hour budget window are hidden. Behavior is unchanged as of v2.1.170.
Environment
- Claude Code v2.1.170, macOS 15.x
- Reproduced in CLI overlay and Desktop App popover
- claude.ai/settings/usage shows correct precision in same browser session
3 Comments
Confirming this from a separate environment, with two additional data points that suggest the bug is broader than the macOS/hours case above:
resets 2:10am (Asia/Jerusalem)with local time00:50(≈1h 20m remaining), and the banner showedresets in 1h— the trailing 20m were floored away, same root cause as the3h/3h56mexample here.2.1.195, running inside Antigravity IDE 1.107.0. So it's not limited toplatform:macos.Suggested fix direction (same as discussed): emit the next-smaller unit on a non-zero remainder (
1h 20m, capped at 2 components) or round rather than floor, and consider falling back to the absolute reset clock time for longer waits.(Filed #71925 before finding this — closing that as a duplicate of this issue.)
Periodic verification — July 2026
Checked against Claude Code v2.1.216 (latest release as of 2026-07-21).
Reproduction test: ℹ️ Not testable this run — the floor-truncation of the reset countdown is only observable while a rate limit is actively counting down, and no rate limit is active at run time. The defect is a display-formatting issue (
floor(hours)instead of rounding or showingHh Mm), not a state that changes between releases.Release notes through v2.1.216: no mention of a fix.
This comment is posted automatically every ~20 days to prevent stale-bot closure (threshold: 28 days). Reporter (@blwfish) will close upon confirming resolved.
Periodic verification — August 2026
Checked against Claude Code v2.1.238 (latest release as of 2026-08-21).
Reproduction test: ℹ️ Not testable this run — the account is not currently rate-limited, so there is no live countdown to compare against the true remaining time.
Release notes through v2.1.238: no mention of a fix. The only countdown-related entry is v2.1.228 ("the retry countdown and stall hint now appear during compaction"), which concerns compaction progress, not the rate-limit reset display.
This comment is posted automatically every ~20 days to prevent stale-bot closure (threshold: 28 days). Reporter (@blwfish) will close upon confirming resolved.