[BUG] Statusline shows incorrect 5hr and weekly usage percentages (e.g. 100%, 900%)

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 Claude Code statusline at the bottom of the terminal displays incorrect usage percentages for both the 5-hour and weekly rate limits.

Example statusline:
Opus 4.6 high · 5hr: 100% (4h 17m) · wk: 900% (5d 16h) · ctx: 15% · hillmanchan:main

• 5hr: 100% shows 100% usage even when the limit hasn't been hit — I can still use Claude Code normally with no throttling.
• wk: 900% shows 900% which is clearly impossible and doesn't reflect actual weekly usage.

The percentages appear to be calculated incorrectly or are reading wrong values from the API rate limit headers.

What Should Happen?

The statusline should display accurate usage percentages that reflect actual API consumption. Values should not exceed 100% under normal circumstances, and should correlate with actual rate limiting behavior (i.e., if I'm not being throttled, it shouldn't show 100%).

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code CLI in terminal
2. Start a conversation (any prompt works)
3. Observe the statusline at the bottom of the terminal
4. Note the 5hr: and wk: percentage values
5. The percentages show inflated/incorrect values (e.g., 100% for 5hr, 900% for weekly) despite normal usage and no throttling

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.71 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The statusline consistently shows inflated percentages. Example observed:

• 5hr: 100% (4h 17m) — claims 100% of 5-hour limit used, with 4h 17m remaining
• wk: 900% (5d 16h) — claims 900% of weekly limit used, with 5d 16h remaining

These values persist across sessions and don't correlate with actual rate limiting behavior (requests continue to work fine). The issue appears to be in how the usage percentage is calculated or displayed from the API rate limit response headers.

Environment:

• macOS Darwin 25.3.0
• Shell: zsh
• Model: Claude Opus 4.6