/context reports incorrect context window ceiling (200k) when actual session window is 1M

Open 💬 1 comment Opened Jun 4, 2026 by paulwilliams71-lang

Summary

/context displays a stale, statically-derived context window ceiling instead of the actual runtime window size. When the effective session window is 1M tokens, /context shows the default 200k ceiling for the model name it reads, producing false \"116% full\" warnings and misleading autocompact guidance.

What the user sees

Context window usage
──────────────────────────────────────────────────────────────────────────────
232,400 / 200,000 tokens used (116%)
──────────────────────────────────────────────────────────────────────────────
⚠ Warning: context window is 116% full. Autocompact should have triggered.

The warning implies the session has blown past its limit and that autocompact has malfunctioned.

What actually happens

The session continues running normally: no autocompact fires, no API errors, no context-length rejections. The session reached 232k+ tokens and kept going without issue — proving the actual window is larger than 200k.

Reproduction context

  • Project .claude/settings.json: "model": "sonnet" (resolves to claude-sonnet-4-6)
  • Global ~/.claude/settings.json: "model": "opus[1m]" (or equivalent 1M-context SKU)
  • Session model reported by /context: claude-sonnet-4-6
  • Context ceiling reported: 200k (the default for claude-sonnet-4-6)
  • Actual session behavior: window is effectively 1M; session ran to 232k+ tokens without any compaction or API error

The project-level "model": "sonnet" setting takes precedence for the model name that /context displays, but the actual API-level context window is resolved to 1M (possibly inheriting from the global SKU, API plan entitlement, or runtime negotiation). /context does not read the actual API-reported window — it maps the displayed model name to a hardcoded default ceiling.

Hypothesis

/context performs a static model-name → default-context-size lookup (e.g. claude-sonnet-4-6 → 200_000) rather than querying the actual context window size returned by the API or advertised in the model's capabilities at runtime. The two can diverge when:

  1. A global settings file selects a 1M-context SKU (e.g. opus[1m], sonnet[1m]) while the project overrides the model name to a standard SKU.
  2. An API key or subscription entitles the user to extended context on a model that defaults to 200k.
  3. Any future model or SKU whose window differs from the static table entry.

Impact

  • Misleading warnings: operators see "116% full" and believe they are about to lose context or that the system is broken.
  • False autocompact alarms: the warning states autocompact should have triggered but didn't, implying a malfunction in a feature that is actually working correctly (it has nothing to compact because the real window is not full).
  • Operator confusion: users may abort sessions, add unnecessary /compact calls, or file support tickets due to a display artifact.

Expected behavior

/context should report the context window ceiling that the API actually enforces for this session — not a ceiling derived from a static model-name lookup. The runtime window size should be authoritative.

Workaround

None at present. The session continues functioning correctly; the display is the only broken element.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗