Usage-limit banner floors reset time ('resets in 1h' when 1h 20m remains)

Summary

The usage/rate-limit banner humanizes the reset time by flooring to the largest whole unit, which drops meaningful minutes and misleads users about when access actually returns.

In my case the underlying API response said the limit resets 2:10am (Asia/Jerusalem). Local time was 00:50, i.e. 1h 20m remaining. The banner, however, displayed:

resets in 1h

That reads as "about 60 minutes," but the true wait was 80 minutes — a 33% understatement. A user who comes back at the "1h" mark is still locked out for another 20 minutes.

Steps to reproduce

1. Hit a usage/rate limit where the reset timestamp is not an exact whole-hour offset from now (e.g. 1h 20m away).
2. Observe the banner text rendered from that reset time.

Expected

The humanized duration should preserve sub-unit precision, e.g.:

• resets in 1h 20m, or
• round to nearest rather than floor (resets in ~1h 20m), or
• fall back to the absolute time for longer waits (resets at 2:10am).

Actual

resets in 1h — the trailing 20 minutes are silently truncated because the duration is floored to the largest whole unit.

Likely root cause

The time-humanization helper appears to take the largest unit and Math.floor() it (floor(80min / 60) = 1h) without emitting a remainder component. Two precision-preserving options:

• Emit the next-smaller unit when a non-zero remainder exists: 1h 20m (cap at 2 components so it stays readable).
• Or compute the label by rounding the total duration rather than flooring, and consider showing the absolute reset clock time for waits over ~1h since the relative phrasing loses value at that range.

Environment

| | |
|---|---|
| Claude Code extension | anthropic.claude-code 2.1.195 |
| Host editor | Antigravity IDE 1.107.0 (VS Code 1.107 base), win32-x64 |
| API reset string seen | resets 2:10am (Asia/Jerusalem) |
| Local time at observation | 00:50 (≈1h 20m remaining) |
| Banner shown | resets in 1h |

Impact

Low severity, but recurring and trust-eroding: any reset that is not a clean whole-hour/whole-minute offset is reported optimistically, so users repeatedly retry too early and perceive the limit as "stuck."