/context reports incorrect context window ceiling (200k) when actual session window is 1M
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 toclaude-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:
- 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. - An API key or subscription entitles the user to extended context on a model that defaults to 200k.
- 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
/compactcalls, 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗