[BUG] /context panel and Plan usage dropdown show ~7x different values for "Context window" in same session (Claude Desktop, Cmd+3)

Summary

In the Claude Code pane of the Claude Desktop macOS app (Cmd+3 tab), the /context panel and the Plan‑usage dropdown both display a field labelled "Context window", but the two values disagree by roughly 7× at the same moment in the same session. The /context panel's internal accounting is also self‑inconsistent.

Observed behaviour

Same session, same instant, both readouts visible simultaneously (see screenshot):

| UI element | Value shown | Percent |
| --- | --- | --- |
| /context panel (top of conversation) | 79.1k / 1.0M | 8 % |
| Plan‑usage dropdown (bottom‑right) | 555.7k / 1.0M | 56 % |

The two are labelled identically ("Context window"), framed identically (X / 1.0M), and use the same bar‑meter styling, strongly implying the same metric.

Why this is inconsistent

1. Same label, ~7× apart. Users cannot tell which one to trust when deciding whether to /compact.
2. Internal math contradiction in the /context panel. The panel reports Free space: 887.9k (88.8 %), which leaves ~112k as used. But the dropdown claims 555.7k used. 887.9k + 555.7k = 1,443.6k > 1,000k, so the two accountings cannot both be literal truths under the same "1.0M window" denominator.
3. Mixed units in the /context panel's right‑most column. The upper rows show percentages (0.1 %, 1.2 %, …) while the lower rows show raw counts (176, 3, 23) with no column header, divider, or unit marker to indicate the switch.
4. Duplicated row names. MCP tools, Memory files, and Custom agents appear twice in the same table — once as kB usage in the top section and again as raw item counts at the bottom — with no visible separator between the two sub‑tables.

Expected behaviour

Either:

• Reconcile both readouts into a single consistent accounting under the label "Context window", or
• Use distinct labels for what are actually two different metrics (e.g. "Current request size (post‑cache‑read)" vs. "Session accumulated context incl. cache writes / deferred tool schemas").

And in the /context panel specifically:

• Add a section header or divider before the second sub‑table so the transition from percentages to item counts is obvious.
• Add a column header indicating units for each of the two right‑hand columns.

Hypothesis on root cause

Plausibly the two numbers measure different things and neither is wrong in isolation:

• /context panel → size of the payload actually transmitted this turn after prompt caching and deferred‑tool elision.
• Plan‑usage dropdown → session‑accumulated uncached token footprint (cache creation + deferred tool schemas + full message history).

Both are defensible internally, but they must not share the same label with the same X / 1M framing, because end users read them as the same quantity.

Impact on user decisions

Users like me actively tune prompt caching (ENABLE_PROMPT_CACHING_1H=1), decide when to /compact, and plan long sessions based on these numbers. "8 % used" and "56 % used" lead to completely different behaviours (continue vs. compact now). The mislabel therefore directly affects context hygiene.

Environment

• Product: Claude Desktop (macOS app), inside the Cmd+3 "Claude Code" pane
• OS: macOS (Apple Silicon)
• Model: Opus 4.7 · 1M context · Max plan
• Mode: Bypass permissions
• Project directory: ~/GitHub/hale_77
• Date observed: 2026‑04‑23

Screenshot

Screenshot to be attached as a comment / edit after filing (GitHub CLI cannot upload images directly). Shows both readouts in a single frame: the /context panel expanded at the top, and the Plan‑usage dropdown expanded at the bottom‑right.