VS Code extension: context ring ignores autoCompactWindow, giving no warning before auto-compact fires

Summary

With autoCompactWindow set in settings.json, the context ring and its hover text are computed against the model's context window rather than the configured one. The percentage shown is wrong, the hover text's wording is wrong, and — because the ring is suppressed by a hard-coded threshold on that same wrong window — there is effectively no warning at all before auto-compaction fires.

Environment

• Claude Code VS Code extension 2.1.269 (win32-x64); CLI 2.1.158; Windows 11 Enterprise 10.0.26200
• Model: Opus 5, 1M context
• ~/.claude/settings.json contains "autoCompactWindow": 500000

Expected

The ring reflects the configured auto-compact window, and appears far enough ahead of compaction to be actionable.

Actual

The ring first renders at roughly 500k tokens used, and auto-compaction fires almost immediately afterwards. At that moment the hover text reads:

50% of context remaining until auto-compact.

There is none remaining. The bottom-right indicator simultaneously reads 50% context used, which is 500k against the 1M model window — i.e. both numbers are measured against the model window, not the configured one.

Root cause

The ring is rendered by the extension's webview/index.js, and the string autoCompactWindow does not occur anywhere in that bundle:

grep -aoc "autoCompactWindow" webview/index.js   ->  0
grep -aoc "autoCompactWindow" bin/claude.exe     -> 18

The CLI is correct — xRH(tokens, model, autoCompactWindow) -> yX4 returns a pctLeft computed against the resolved window, and $88(model, window) reports the source as settings when it comes from settings.json. The webview is handed the model's window instead:

contextWindow: usageData.contextWindow - usageData.maxOutputTokens - 13000

and the component then does:

let z = J > 0 ? Math.min($/J*100, 100) : 0;   // $ = tokens used, J = the value above
let U = 100 - z;
if (U >= 50) return null;                      // ring suppressed while >= 50% remaining
title:  `${Math.round(z)}% context used - click to compact`
popup:  `${Math.round(U)}% of context remaining until auto-compact.`

Note this mirrors the CLI's own compaction arithmetic — the same max-output reserve, the same 13,000-token buffer — with only the window substituted. That is why the numbers look plausible rather than obviously broken.

Two distinct defects fall out of this

1. The hover text is mislabelled. U is percent of the model window remaining. The string calls it "remaining until auto-compact". Those are the same quantity only when autoCompactWindow is unset.

2. if (U >= 50) return null is hard-coded against the model window. On a 1M model the ring therefore cannot render below roughly 461k–494k tokens used (the range reflects maxOutputTokens, which varies by model). Consequences:

| autoCompactWindow | Warning runway before compaction |
|---|---|
| below ~500k | none — the ring never renders first |
| 500k | ~zero; the render threshold and the compaction point coincide |
| 600k | roughly 30k–125k tokens |

The second row is the reported case. The first row is the more serious one, because it inverts user intent: lowering autoCompactWindow to compact sooner removes the warning entirely rather than buying headroom. A user reacting to this bug in the obvious way makes it worse.

Suggested fix

Thread the resolved window — the CLI's ul(model, autoCompactWindow).window — through to the webview, and use it both for the percentage and for the render threshold. The suppression threshold should be derived from that window rather than hard-coded at 50, otherwise a small configured window still yields no warning.

Workaround

Set autoCompactWindow above ~500k on a 1M model. Usable runway is approximately autoCompactWindow - 500000.

Related, but not duplicates

• #90756 (Desktop: expose the auto-compact window in the usage ring) — that asks for a UI control to set the value. This issue is about the ring misreporting once the value has been set by any route.
• #91385 (Context ring no longer warns before the window limit) — that concerns the hard per-prompt window being hit mid-turn, where compaction cannot help, and explicitly notes that autoCompactWindow governs compaction rather than the indicator. This issue is the narrower, source-level cause on the indicator side: the configured window is absent from the webview bundle, and the render threshold is a hard-coded constant.

Scope caveat

Measured against the VS Code extension bundle specifically. The desktop app very likely shares this webview — #91385 reports comparable symptoms there — but I have not verified the desktop bundle, so the title is deliberately scoped to what was actually measured.