Claude Code hung. Which status signal is actually telling you what happened?

The status line at the bottom of the terminal reads context_window.used_percentage from a JSON object piped over stdin. That is local context-window utilization, not server-side quota. To check if you've actually been rate-limited, open claude.ai/settings/usage in a browser tab. If the five-hour or seven-day bar is at or near 100 percent, the hang is a rate-limit and waiting is the only fix until resets_at. If both bars are clean and the process has consumed zero tokens for several minutes, the hang is client-side, almost certainly the streaming-stall pattern from issue #25979 or the wedged-renderer pattern from issue #25286, and SIGKILL is safe.

It is a customizable bar fed by a script you write. Claude Code pipes a JSON object to that script's stdin on each update, with fields for the model display name, the workspace directory, cost so far in the session, and context_window.used_percentage. A common config is jq -r '"[\(.model.display_name)] \(.context_window.used_percentage // 0)% context"'. Every field is computed inside the local CLI process. There is no field for server quota, no field for five-hour utilization, and no field for weekly utilization. The status line is a window into the client; it cannot be a window into the server.

Partially, and only retroactively. /status surfaces the current model, the session's local context, and any error from the most recent API call. If your last call returned an anthropic-ratelimit-* header or a 429, you'll see it. But /status does not poll. If you've been hung for five minutes with no requests in flight, /status will show whatever state existed at your last successful call, which is older than the hang itself. It is a snapshot of the past, not a live signal of the rate-limit ceiling.

Not reliably. The spinner is driven by the terminal renderer, not by API progress. Issue #25286 documents a pattern where the renderer keeps animating at a 100 percent write ratio while the underlying request has stalled. Issue #44921 documents a pattern where token consumption sits at zero for 25-30 minutes while the spinner keeps spinning. The spinner means the process is alive. It does not mean a request is moving.

GET the path /api/organizations/{your-org-uuid}/usage on the claude.ai host with your logged-in claude.ai cookies and a Referer header pointing to claude.ai/settings/usage. The response is JSON with seven Window objects (five_hour, seven_day, seven_day_sonnet, seven_day_opus, seven_day_oauth_apps, seven_day_omelette, seven_day_cowork) each shaped { utilization: f64, resets_at: Option<DateTime<Utc>> }. The same endpoint claude.ai/settings/usage renders the bar from. If five_hour.utilization is at or near 1.0, you've been rate-limited. ClaudeMeter polls this endpoint once a minute via your existing browser session and renders the worst bucket in the macOS menu bar.

Because ccusage walks ~/.claude/projects/*.jsonl and sums local input/output tokens. That sum is correct as a token-flow measurement on this device. It is not the function the server's rate-limiter is computing. The server applies weights local logs cannot see (a peak-hour multiplier on weekday US Pacific midday hours, a per-attachment cost, a per-tool-call cost, a per-model weight where Opus burns faster than Sonnet for the same prompt, plus any traffic from claude.ai browser chats or other devices on the same account). The local sum and the server's utilization can diverge by an order of magnitude. There are reproducible reports of ccusage saying 5 percent while claude.ai 429s the next request.

Three things, in this order. (1) Don't SIGKILL; the next prompt will hit the same wall. (2) Read resets_at to know when the wall lifts; the value is an ISO timestamp like 2026-05-09T19:22:00Z, which is when the oldest chargeable traffic in the bucket ages out. (3) If extra usage is enabled on your plan, switch to it for the rest of the session: Anthropic's metered overage path keeps working when the rolling-window bucket is full. ClaudeMeter renders the dollar amount used on extra usage next to the bar so you can see where you stand at a glance.

It's a client-side stall. The four documented patterns: (1) the stream-json mode hang on issue #25629, where stdout buffering wedges after the result event; (2) the streaming-stall hang on issue #25979, where the SSE connection stops emitting events but the request stays open with no read timeout; (3) the wedged-renderer hang on issue #25286, where the terminal renderer reaches 100 percent write ratio and refuses input; (4) the zero-token-consumption hang on issue #44921, where the process runs but never sends a request. Press Esc once. If the process doesn't recover in 30 seconds, run pkill -f claude in another shell.

Those are on responses from the Anthropic API surface (api.anthropic.com), not from claude.ai. They give you the most restrictive currently-active API rate limit for your API key (tokens-per-minute, requests-per-minute, input-tokens-remaining). They do not expose the rolling 5-hour or 7-day consumer-plan utilization that gates Claude Code on a Pro or Max subscription. The consumer plan's utilization comes back only on the private claude.ai endpoint. Different surface, different contract, not interchangeable.

Because the CLI is given an API key or session credential at startup and talks only to api.anthropic.com or the equivalent Claude Code-specific endpoint. The consumer-plan quota lives on claude.ai under a different cookie scope. To bridge them, something has to call claude.ai/api/organizations/{org}/usage with your browser cookies and feed the result somewhere visible. That's exactly what ClaudeMeter's browser extension does: it runs inside Chrome, calls the endpoint with credentials: 'include', and POSTs the snapshot to the menu-bar app on localhost:63762. The status line could in principle shell out to that bridge, but it doesn't ship that way out of the box.