Let the Code tab's usage ring report session context, not only the 5-hour window

Surface: Claude Code in the Claude Desktop app (Code tab). Not the chat
app — #20041 was closed as "not about Claude Code", and this is not that.
entrypoint: claude-desktop, Claude Code v2.1.255, Windows 10, model
opus[1m] (1,000,000-token context).

Problem

The footer's circular usage indicator reports the five-hour rate-limit
window. The session's context usage is behind a click on that ring:

Click the usage ring next to the model picker to see your current context window usage and your plan usage for the period. Context usage is per session; plan usage is shared across all your Claude Code surfaces. — desktop docs

Those two numbers are not equally useful moment to moment:

• Five-hour usage is not actionable. You can only wait it out.
• Context is entirely actionable. Knowing you are at 85% is what tells you

to compact deliberately, split the task, or bank the work before a
compaction lands mid-run.

The result is being surprised by compaction in the middle of long sessions,
with no ambient cue that it was coming. On a 1M-token window the run-up is
long enough to plan around, if you can see it.

Why the existing workarounds do not cover this surface

1. statusLine is terminal-only. It is the documented way to show

context_window.used_percentage, and it renders nothing in the desktop
app. The desktop documentation never mentions it. Two full restarts were
spent discovering that, because nothing reports the setting as inapplicable
— it is silently inert.

1. No setting controls the ring. The settings reference has no key for

what it measures (footerLinksRegexes, showTurnDuration and the
spinner* keys are the nearest neighbours, and none apply).

1. A hook systemMessage is collapsed into a "Claude Code notice"

chevron — visible only on a click, which is the same problem again.

Request

Small and display-only — the ring already computes both numbers:

• Preferred: let the ring report session context, with plan usage on the

click; or show both, e.g. a two-segment ring or 31% ctx · 63% 5h.

• Or: a settings key such as usageRingReports: "context" | "plan".
• Or, least of all: honour statusLine in the desktop app, so the

documented escape hatch actually exists on this surface.

Not a duplicate

• #20041 (closed, not planned) — the Claude Desktop chat app, closed for

being out of scope. This is the Code tab.

• #7111 (closed, completed) — restored indicators; an indicator now exists.

This is about which metric it reports and that it needs a click.

• #17431 (closed, not planned) — usage-limit visibility, i.e. the

five-hour window. This is the opposite ask: the context number.

• #18705 (open) — hitting the limit with no warning. Same underlying pain,

from the failure end; this asks for the ambient signal that would prevent it.

Workaround, for anyone landing here

A Stop hook writes the session's context each turn, and a small always-on-top
window reads it. Context in the window is the last assistant response's
input_tokens + cache_creation_input_tokens + cache_read_input_tokens +
output_tokens, taken from the tail of transcript_path. It works, but it is
an external window with a Startup shortcut to replace a number the app is
already displaying behind a click.