Desktop app: bring back the context-usage indicator (or make the footer widget configurable)

Related open reports: #85437 (the round indicator multiplexes context and rate-limit counters, with no way to tell which one is displayed) and #85010 (the footer meter computes against 200K on 1M-context models).

Additional data point for this request: until recently the round indicator showed context usage by default, at a glance, with no hover or click needed. After an app update it now defaults to the 5-hour usage limit instead. The timing matches the staggered rollout described in #85437 (around 2026-08-27). So from the user's perspective this is a regression in which counter the indicator shows by default, not only a missing feature.

Windows 11, desktop app, latest channel.

+1 — this change broke a real workflow for me.

I run many parallel desktop sessions (one per page of an app I'm building) and rotate each session to a fresh prompt when its context fills up. The context ring was how I knew it was time, at a glance, across a dozen sessions. The weekly-usage ring doesn't change any decision mid-session, and /context being on-demand only means checking every session by hand.

Any of the three options in the description would work for me; a configurable footer widget would be ideal.

Windows 11, desktop app, latest channel. (Filed with an assist from Claude Code itself.)

Confirming on Windows 11, desktop 1.40609.1 (2026-08-30 build). Same behavior: the footer ring now shows the 5-hour plan limit, and context usage is only visible by clicking the ring or running /context.

Two things worth adding:

1. The change isn't in the desktop changelog for 1.40609.0, 1.40609.1, or 1.44121.1, so it appears to have shipped silently.
2. It also removed the only ambient warning before compaction. #91232 and #91385 are the downstream reports: sessions now hit auto-compact or "Prompt is too long" with no visual lead-up, because the ring is no longer measuring the context window.

Plan usage barely moves within a session and is already available in Settings > Usage. Context usage changes every turn and drives real decisions (compact now, wrap up, split the task). Swapping the persistent indicator from the one that matters mid-session to the one that doesn't is a net loss for anyone running long agentic sessions.

The old way was simply more user friendly: one glance at the ring told you where the session stood, with no clicks and no commands. That is exactly what a persistent indicator is for.

Any of the three options in the original post would resolve it. A footer toggle (context / plan / both) is the smallest change. Honoring statusLine in the desktop view would be the most general.

+1. Concrete ask from a desktop-app user: show two rings side by side in the footer, one for context-window usage and one for the 5-hour/weekly plan usage, instead of a single ring that needs a click every time. Or at minimum a setting to pick which metric the ring shows persistently. Both numbers are useful, but having to click each time breaks flow in long agentic sessions. macOS, Claude Code desktop app, Fable 5.1.

I'm kind of confused what's going on here. Clicking the footer ring in a new chat session created inside the Desktop app's Code section, I get a context window break down:
<img width="483" height="290" alt="Image" src="https://github.com/user-attachments/assets/ede143ac-107c-42fd-9ed9-c85118307d44" />

However, opening a session that was originally created inside VS Code, in the exact same place in the Desktop app does not give me the context window view - even when sending some messages via the desktop app in that session:
<img width="458" height="216" alt="Image" src="https://github.com/user-attachments/assets/cc7a9737-84d7-47df-8707-eaded1bd059c" />

Sessions inside the "Home" section doesn't even show me the "ring widget" in the footer...

+1, with a use case I don't think is represented yet: a single long-running agentic session, rather than many short or parallel ones.

I use Claude Code to orchestrate multi-hour builds. In the session I'm in as I write this, it has generated and verified ~80 pages of a site conversion — running an extractor, a renderer, a save-time lint and a browser-based fidelity harness end to end, across many turns. That is one continuous context, not a dozen rotating ones.

In that mode the context number is the only one that informs a decision, and it informs several:

• whether to split the next unit of work or keep going in-context
• whether to hand a sub-task to a subagent specifically to keep the main context clear
• whether to stop at a clean boundary and let it compact, rather than have compaction land in the middle of a verification run

The rate-limit ring answers none of those. It barely moves within a session, and on the rare occasion it does, there is nothing I would do differently that turn.

Clicking the ring works, and /context works, but both are pull. The value of a persistent indicator is that it is ambient — I read the ring constantly without deciding to. I don't run /context on a cadence, so in practice I now don't know where a session stands until something goes wrong, which is exactly the failure mode #91232 and #91385 describe.

Option 2 (configurable footer widget) looks like the best fit to me: whoever wants the plan ring keeps it, and nobody has to win an argument about which default is correct. Option 3 would be better still for anyone already maintaining a statusLine, since it reuses a setting that exists rather than adding one.

Linux and Windows, Claude Code, latest — same behaviour on both workstations. (Written with an assist from the session described above.)

Can we restore the ring or at least have an option in settings to enable it?

Update 2026-10-14, desktop app 2.37337.1 on Windows 11, Max plan.

Since #91712 / #91075 were closed as completed (2026-09-15) the ring did show context usage again — until yesterday. Now it shows the weekly limit again, and the reason seems to be a hidden rule, not a regression: the ring switches to a plan window as soon as that window is "high". My numbers right now: 5-hour 7 %, weekly all models 85 %, weekly Fable 68 %, session context 21 % of 1M. The ring shows the 85 % weekly and there is no way to get the context ring back until the weekly resets (Friday).

Two problems with that rule:

1. I cannot choose. The context fill is the number that changes what I do mid-session (compact, hand off, start fresh). The weekly number changes nothing minute to minute. A high weekly is exactly the time I want to watch context closely, because every re-read of a big context is what burns the weekly. Please make the metric a user choice (ring = context / 5-hour / weekly), or show two rings. Any threshold override should be opt-in.

1. Extra usage makes the warning misleading. I have extra usage enabled (monthly cap set). When the weekly hits 100 % nothing blocks, the session just bills to extra usage. Does the ring then sit at 100 % red for the rest of the week, hiding context the whole time, although the limit is no longer a limit for me? That is the worst case for this rule: the warning is permanent exactly when it is irrelevant.

Confirmed again today: no setting in the desktop app controls the ring or the threshold (checked the Code tab settings). /context and clicking the ring still work, but that is on demand, not at a glance.

Same here on Linux (Ubuntu 24.04), desktop app 2.37337.1, updated today. Clicking the ring next to the model picker only shows the plan limits (5-hour and weekly). There is no context breakdown in the popover at all, not just in the ring. Before this update the popover showed the context usage. /context still works, but there is no at-a-glance view any more. +1 for letting us choose what the ring shows, or showing context and limits side by side.

Confirming on macOS, desktop app 2.37337.1 (Claude Code 2.1.295), Max plan, updated Oct 13.

The usage popover next to the model picker now shows only the session limit and the weekly limit. There is no context-window percentage anywhere in the Code tab. It was visible before this update.

The data still exists: the session usage tool (get_usage) returns the context for the same session (161,172 of 1,000,000 tokens, 16%, auto-compact at 97%). It is just no longer drawn in the UI.

Why it matters: I run long sessions with many subagents. Without the meter I can't tell when auto-compaction is near, or when to wrap up or hand off. /context is on demand only, and statusLine does not render in the desktop chat view.

Please restore the context meter in the Code tab (or make the footer widget configurable). This looks like a regression in 2.37337.1, also reported on Windows and Linux above, and in #102130.

For anyone who wants this now, a stopgap: a small mod that keeps context 27% · session 25% · weekly 33% · Fable 36% as one line above the prompt, desktop and terminal. Details, screenshot and install steps in https://github.com/anthropics/claude-code/issues/102094#issuecomment-6179264725 — repo at https://github.com/JiahaoXu10Arthur/context-band.

Adding my vote. Until yesterday I relied on the color-coded ring (blue, then yellow, then red) to tell me when a thread's context window was filling up. That was my cue to write a briefing and run /compact before quality dropped. Today, on the latest desktop build, the ring and the popover show only my session and weekly plan limits. There's no context number anywhere unless I remember to type /context.

Plan usage and context fill are different questions. Plan usage is account-wide and I check it occasionally. Context fill is per thread and I need it at a glance while I work. Please bring back a color-coded context indicator, or let me choose what the ring tracks. At minimum, put the context row back in the popover the way the docs describe.

Max (20x) plan, macOS, Claude Code desktop app, Opus 5.5 with 1M context.