claude-code - 💡(How to fix) Fix /usage Usage tab silently degrades to qualitative-only — no progress bars, no error [1 comments, 2 participants]

Summary

On Claude Code 2.1.119 with a Claude Max account, the /usage Usage tab never renders the 5-hour or weekly limit progress bars. It silently falls back to a "What's contributing to your limits usage?" qualitative panel with zero indication that the actual limits data is missing.

This contradicts:

• 2.1.119 changelog: "Fixed /usage progress bars overlapping with their 'Resets …' labels" — implies bars + reset times are supposed to render.
• 2.1.116 changelog: "The Usage tab in Settings now shows your 5-hour and weekly usage immediately and no longer fails when the usage endpoint is rate-limited" — implies a known failure mode where the limits endpoint can return no data, and the client should handle it visibly.

For me, the failure mode appears to be: endpoint returns nothing (or the client doesn't render its response), and the UI quietly shows only the qualitative breakdown. No "limits unavailable" message, no error, no progress bars at all.

Repro

1. /usage → Usage tab on 2.1.119, Max account
2. Press d (day) — full screen output:

``` Session Total cost: $0.92 Total duration (API): 3m 23s Total duration (wall): 10m 41s Total code changes: 0 lines added, 0 lines removed Usage by model: claude-opus-4-7: 34 input, 10.6k output, 581.9k cache read, 36.6k cache write ($0.78) claude-haiku-4-5: 26.9k input, 1.9k output, 85.7k cache read, 64.7k cache write, 1 web search ($0.1356)

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

96% of your usage was at >150k context Longer sessions are more expensive even when cached. /compact mid-task, /clear when switching to new tasks.

d to day · w to week ```

1. Press `w` (week) — same structure, different qualitative bullets ("80% at >150k context", "49% subagent-heavy", "17% 8+ hour sessions"). No bars, no reset times.

There is no progress bar, no "Resets …" label, no numeric "X% of 5-hour" or "X% of weekly used" anywhere in either mode.

Expected

Per the 2.1.119 changelog entry, both `d` and `w` views should render progress bars with "Resets …" labels showing actual quota consumption. If the limits endpoint can't return data, the UI should say so explicitly rather than silently presenting the qualitative panel as if it were the whole story.

Why this matters

I'm running `anthropics/claude-code-action@v1` in CI authenticated via `CLAUDE_CODE_OAUTH_TOKEN` — every workflow run consumes my Max plan's 5-hour and weekly windows, not API billing. A daily-cron 7-language matrix fans out one Action invocation per language. Without a working in-CLI limits readout, I can't tell how much headroom remains before dispatching additional manual runs or interactive sessions on the same plan.

The silent degradation is the real harm: the qualitative panel looks complete, so it's easy to assume nothing is missing.

Environment

• Claude Code: 2.1.119
• Login: Claude Max account
• OS: macOS (Darwin 24.6.0)
• Terminal: alacritty running inside tmux

Suggested fixes

1. When the limits endpoint returns no usable data, render an explicit "Limits temporarily unavailable" affordance rather than silently presenting the qualitative panel alone.
2. Verify the endpoint actually responds for Max-plan OAuth sessions (in case it's an auth/scope mismatch on the server side).
3. Consider exposing a `--debug-usage` or similar to surface the raw endpoint response/error for users filing reports like this one.