`/usage` Usage tab shows no rate-limit progress bars (still reproduces on 2.1.280) — silently falls back to qualitative-only panel

Status Open
Reported on v2.1.280
Maintainer reply None cached
Activity 1 comment · opened Sep 22, 2026

Summary

On Claude Code 2.1.280, /usage → Usage tab never renders the 5-hour/weekly rate-limit progress bars or "Resets …" labels. It silently falls back to the "What's contributing to your limits usage?" qualitative-only panel, with no indication anything is missing.

This is the same symptom already reported in #53735 (filed on 2.1.119, 2026-04-27) and #49633 (filed on 2.1.112, 2026-04-17). Both were closed by the repo's automated duplicate/stale bot without a maintainer confirming a fix: #53735 was closed as "duplicate" of #49633, and #49633 itself was closed by an inactivity-bot comment ("Closing for now — inactive for too long"), recorded with state_reason: not_planned. Five months later, on 2.1.280, the same user-visible symptom reproduces, down to the identical panel heading text.

Repro

  1. Run claude (v2.1.280), authenticated via the CLAUDE_CODE_OAUTH_TOKEN environment variable rather than an interactive claude login session.
  2. /usage → Usage tab.
  3. Output is:

```
Session
Total cost: ...
Total duration (API): ...
Usage by model: ...
Prompt cache (main): ...

What's contributing to your limits usage?
Approximate, based on local sessions on this machine — does not include other devices or claude.ai

Last 24h · these are independent characteristics of your usage, not a breakdown
93% of your usage was at >150k context
...

d to day · w to week
``
No progress bar, no numeric "X% of 5-hour/weekly used," and no "Resets …" label appear in either
d (day) or w` (week) mode.

Evidence that related rate-limit UI text is still present in the build

Strings extracted from the installed claude.exe binary (v2.1.280) include rate-limit progress-bar UI text:

5-hour session limit
Approaching your 5-hour usage limit
To display both 5-hour and 7-day limits when available

This confirms related UI strings are still packaged in this build. It does not identify whether the missing display is caused by an unavailable endpoint, missing data, account eligibility, or a rendering-path condition.

Rate-limit data is available in the same session, but /usage does not display it

This session authenticates via CLAUDE_CODE_OAUTH_TOKEN (env var), the same mechanism the original #53735 reporter used in CI. That made env-var auth a plausible suspect for the missing data. This session's status line (a separate, documented feature — rate_limits.five_hour/rate_limits.seven_day, each with used_percentage and resets_at) is populated correctly at the same time /usage shows no bars. The following is the rate_limits object from the statusline JSON:

{"five_hour":{"used_percentage":5,"resets_at":1790115600},"seven_day":{"used_percentage":1,"resets_at":1790694000}}

This shows that usable rate-limit data is available during the same OAuth-env-token session in which /usage shows no bars. It makes a general data-availability or env-var-auth explanation unlikely. The defect appears specific to /usage's Usage-tab path — whether that is its data acquisition, eligibility/gating logic, or rendering — not to the account's ability to obtain rate-limit data.

Environment

  • Claude Code: 2.1.280
  • OS: Linux 5.14.0-687.42.1.el9_8.x86_64
  • Auth: OAuth token supplied via CLAUDE_CODE_OAUTH_TOKEN env var (not an API key, not interactive login)
  • Related: #53735, #49633

Suggested UX fallback

Same as originally suggested in #53735: if rate-limit data is unavailable or unusable, consider showing an explicit "Limits temporarily unavailable" state rather than presenting only the qualitative panel without indicating that quantitative rate-limit information is absent.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗