Desktop: Expose the auto-compact window in the usage ring that already shows context usage

What's missing

Desktop shows the number and withholds the lever.

Clicking the usage ring next to the model picker shows the session's current context window usage. That number is the main driver of what a long session costs against plan limits, because the whole conversation is re-sent with every request. The setting that governs it, autoCompactWindow, has no control I can find anywhere in the Desktop UI: not in the ring popover, not in Settings → Claude Code, not next to the model and permission-mode selectors.

Nor is there a documented one. The Desktop page never mentions autoCompactWindow or /autocompact; it documents /compact for freeing context and stops there. The settings reference notes for autoCompactEnabled that it "Appears in /config as Auto-compact", and gives autoCompactWindow no equivalent line. If a control does exist somewhere I have missed, that is itself the discoverability problem this issue is about.

Why this is a Desktop issue and not a general one

The CLI has three answers to this that Desktop does not have:

• /autocompact <value> typed into a session. The argument form may well work in a Code tab — the Desktop docs list terminal-dialog commands under "What's not available in Desktop" but name only the no-argument forms, such as /permissions, as refusing outright. Either way, a slash command that the Desktop page never mentions is not a UI.
• claude --autocompact <value> at launch. Desktop users do not launch the app from a command line, and the CLI-flag-equivalents table in the Desktop docs — which does give Desktop equivalents for --model, --permission-mode, --verbose, and MAX_THINKING_TOKENS — has no row for this one.
• A custom status line rendering context_window.used_percentage continuously. That is a terminal mechanism.

What remains for a Desktop user is hand-editing ~/.claude/settings.json, or installing and learning the CLI in order to configure the GUI.

Why it matters

On Max, Team, and Enterprise plans, Opus is automatically upgraded to 1M context with no additional configuration. A Desktop user's default is therefore a window that lets a session grow toward 1M tokens before anything compacts, and every tool call after saturation re-reads that context. The cost documentation states the mechanism plainly: Claude Code sends the full conversation with every request, so a one-line question in a session that has been open all day still draws usage for the whole conversation.

#87646 measured what that costs. On one Max 20x machine, 91% of spend over a 48-hour window was context being re-processed rather than generated, and requests above 500K context were 24.9% of requests but 52.4% of cache-read spend. That report notes the mitigation is "a large, easy win hidden behind an undocumented-in-practice key". On Desktop it is hidden behind a key with no UI at all.

Proposed

Preferred: put it in the usage ring popover, next to the model picker.

That popover already reports the session's context window usage. It is the one place in the app where a user is looking at this number, and they are usually looking at it precisely because they are worried about it. Adding a single control there — Auto-compact at: with Auto, 200K, 300K, 500K, 1M — puts the lever next to the reading it governs, at the moment it is wanted. It sits naturally beside the model picker and the effort selector, which are the other two per-session choices with a direct cost consequence.

Also, or otherwise: a row in Settings → Claude Code, alongside the settings already there such as worktree location and auto-archive.

Either placement should:

• Write autoCompactWindow to ~/.claude/settings.json, the same key /autocompact writes, so Desktop and CLI stay consistent on a machine where both are used.
• Show the effective value read-only, marked as managed, when a higher-priority settings scope sets the key — matching what /autocompact already reports in the CLI.

On the "this is an advanced setting" objection

Worth answering, because it is the obvious reason to leave things as they are.

The setting is advanced. The consequence is not: it is the default, it applies to every user on a plan with the automatic 1M upgrade, and it is charged silently. More to the point, Desktop is the surface people choose because they would rather not work in a terminal. "Run it from the CLI" is the one answer that does not fit the audience of the surface that lacks the control. An advanced setting can be a collapsed row, a secondary line in a popover, or an entry that only appears once a session has grown — it does not have to be prominent to be reachable.

Related

• #87646 — the cross-surface cost measurement that motivates this, open. This issue is the Desktop control surface, filed separately rather than as a comment there, because they are different components.
• #80261 — persistent usage indicator on the Desktop main screen. Adjacent: that asks for the reading to be glanceable, this asks for the control to exist.
• #20041 — Desktop context usage indicator, closed as not planned by lifecycle automation in February 2026.
• #75335 — the same threshold expressed as a percentage, filed before /autocompact shipped.
• #72062, #70681 — configurable-threshold requests closed as completed on 2026-08-17 with the /autocompact answer. This issue asks for that answer to reach the Desktop UI.

Not proposed here: changing the default window, or reviving CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, which has open reports of silently not taking effect (#52390, #82761).

Environment

| Item | Value |
|---|---|
| Surface | Claude Code Desktop |
| OS | Windows 11 |
| Engine | 2.1.247 |
| Plan tier | Opus with the automatic 1M context upgrade |