[BUG] Opus 4.7 1M context window unreachable in VS Code extension — no documented env var / setting to opt in; client caps at 200k
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Paid Subscription MAX 20x - Opus 4.7 has a 1M-token context window per Anthropic's published model spec. Running claude-opus-4-7 in the Claude Code VS Code extension on Windows, the effective context window behaves as 200k tokens and there is no documented user-reachable setting to opt into the 1M variant from this client.
Observable: the auto-compact tooltip shows 48% of context remaining until auto-compact / 52% context used — click to compact at a token count consistent with a 200k ceiling, not ~500k of a 1M budget. Sessions compact roughly 5× earlier than the 1M spec implies.
On this machine I have configured every knob I could find that might matter, verified on disk:
~/.claude/settings.json:"env": { "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "90" },"autoCompactWindow": 900000- VS Code user
settings.json:"claudeCode.environmentVariables": ["CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90"] - Windows User-scope env vars:
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90,CLAUDE_CODE_EFFORT_LEVEL=max
Subprocess propagation is confirmed working (echo $CLAUDE_AUTOCOMPACT_PCT_OVERRIDE returns 90 inside the integrated terminal of a freshly-launched session). None of these are window-size controls, and I cannot find any setting or env var in the docs that is. Names a user might reasonably try — CLAUDE_CODE_ENABLE_1M_CONTEXT, ANTHROPIC_BETAS=context-1m-2025-08-07, ANTHROPIC_MODEL, MAX_CONTEXT_TOKENS — are either undocumented for Claude Code or silently ignored.
What Should Happen?
When the selected model is claude-opus-4-7 and the user's plan/org has access to the 1M context window, the Claude Code VS Code extension should expose that full 1M window — either by default or via a documented, user-reachable opt-in (env var, setting, CLI flag, or extension preference). The compaction tooltip and token counter should reflect the active ceiling.
If 1M support is no longer implemented in the VS Code extension client, that limitation should be documented plainly so users stop chasing threshold knobs that cannot fix a window-size problem.
Error Messages/Logs
Steps to Reproduce
- On Windows 11, install Claude Code VS Code extension v2.1.114.
- Select model
claude-opus-4-7(via/modelorclaudeCode.selectedModelsetting). - Configure every plausible "larger window" knob available:
- In
~/.claude/settings.json:"env": { "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "90" }and"autoCompactWindow": 900000. - In VS Code user
settings.json:"claudeCode.environmentVariables": ["CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90"]. - At Windows User scope (PowerShell):
[Environment]::SetEnvironmentVariable("CLAUDE_AUTOCOMPACT_PCT_OVERRIDE", "90", "User")
- Fully quit VS Code (
taskkill /F /IM Code.exe /T) and relaunch. Confirm the env var reaches the subprocess:echo $CLAUDE_AUTOCOMPACT_PCT_OVERRIDE→90. - Open a new Claude Code session and work normally.
- Observe: the auto-compact tooltip fires at roughly 50% of a 200k budget, not roughly 50% of a 1M budget. No configuration makes it behave like 1M.
Expected: 1M window (or a documented opt-in that unlocks it).
Actual: 200k ceiling with no apparent escape.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.114 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
There are only two readings of the evidence, and Anthropic should be explicit about which one applies:
- This is a bug. The 1M window is meant to be available to Opus 4.7 users in Claude Code but an extension-side code path is silently capping at 200k. Fix.
- This is a deliberate product decision. The VS Code extension is intentionally capped at 200k regardless of the user's plan or the model's spec. In that case:
- Document the cap, plainly, on the Claude Code docs page and release notes — not buried.
- Stop shipping
CLAUDE_AUTOCOMPACT_PCT_OVERRIDEandautoCompactWindowas configurable surfaces when the underlying window is fixed. They read as knobs a user can turn to get more room; they cannot. Users configuring them are configuring against a product decision they have no way to discover. - Explain the rationale (cost? latency? capacity?), and name the plan tier / interface (if any) that does get 1M, so paying customers can make informed decisions about whether Claude Code is the right client for their work.
What is not acceptable is the current state: a documented model capability (1M) that cannot be reached through the advertised client, with configuration knobs that look meaningful but are no-ops, and no documentation clarifying which of the two readings above is true. That combination — silent cap + configurable-looking but inert settings + no disclosure — is indistinguishable from deliberate throttling presented as a technical limitation. Please resolve it one way or the other.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗