Foundry: `/context` shows 200k cap even with 1M beta enabled and `effectiveWindow=1M` confirmed

Foundry: /context shows 200k cap even with 1M beta enabled and effectiveWindow=1M confirmed

Summary

When running Claude Code through Microsoft Foundry (CLAUDE_CODE_USE_FOUNDRY=1), the TUI /context progress bar continues to display xk/200k even after the 1M context beta is correctly enabled and the autocompact decision path is using ~1M (effectiveWindow=960000 confirmed in debug logs).

Two independent client code paths consult different sources of truth for the context window — they have diverged for the Foundry provider on this version.

Environment

• Claude Code: 2.1.158 (Windows native build, claude launcher)
• Provider: Microsoft Foundry (CLAUDE_CODE_USE_FOUNDRY=1)
• Model: claude-opus-4-7 (Foundry deployment of Opus 4.7)
• OS: Windows 11

Steps to Reproduce

1. Configure Foundry provider in ~/.claude/settings.json:

``json
{
"env": {
"CLAUDE_CODE_USE_FOUNDRY": "1",
"ANTHROPIC_FOUNDRY_RESOURCE": "<your-foundry-resource>",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-7"
}
}
``

1. Launch Claude Code with --betas context-1m-2025-08-07. (Note: setting ANTHROPIC_BETAS=context-1m-2025-08-07 as an env var no longer works — that was a previously working workaround that regressed sometime after v2.1.140. CLI flag still works.)
2. Run claude --betas context-1m-2025-08-07 -p 'hi' --debug --debug-file C:\tmp\cc.log
3. Open an interactive session and run /context.

Expected

• /context shows xk/1000k.

Actual

• /context shows xk/200k.
• Debug log shows the autocompact path is correctly using ~1M:

``
[DEBUG] autocompact: tokens=[REDACTED] level=ok effectiveWindow=960000
[DEBUG] [API:timing] dispatching to foundry model=claude-opus-4-7
``

Diagnosis

The TUI /context renderer reads contextLimit from the bundled PRIMARY_MODELS table. Grepping the binary shows the Foundry-targeted id claude-opus-4-7 (no suffix) is hardcoded to a 200k contextLimit. There IS a separate entry for claude-opus-4-7[1m] mapped to "Opus 4.7 (1M context)", but it is unreachable on Foundry:

• Setting ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-7[1m] causes Foundry's deployment resolver to fail and silently fall back to claude-sonnet-4-6. Debug log confirms:

``
[DEBUG] [API:timing] dispatching to foundry model=claude-sonnet-4-6
`
(Foundry deployment names equal model names without the suffix — there is no claude-opus-4-7[1m]` deployment, so lookup fails.)

The autocompact decision path (effectiveWindow calculation) correctly consumes the --betas flag and uses 1M. The /context UI path does not.

Related

• Same family of bug as the Bedrock provider issue #40753: 1M context is gated client-side behind paths that don't fire for non-Anthropic-direct providers.
• Previously, ANTHROPIC_BETAS=context-1m-2025-08-07 as an env var was sufficient (worked on a build dated 2026-05-19). Sometime after v2.1.140 the effectiveWindow decision path stopped reading this env var. The CLI flag --betas still works for that path but cannot fix the /context rendering.

Suggested Fix

For Foundry (and likely Bedrock), when --betas context-1m-2025-08-07 is active, the contextLimit lookup for the un-suffixed model id should be promoted to 1M — OR the resolver should accept the [1m] suffix and strip it before Foundry deployment lookup (the binary already has the replace-/[1m]$/ regex; it just isn't applied on this path).

Either fix would re-align the two code paths and make /context honest again.

Workaround

Until fixed, users on Foundry can:

1. Inject --betas context-1m-2025-08-07 via launcher to unlock the real ~1M autocompact window.
2. Set autoCompactWindow: 980000 in settings to let the session actually use it.
3. Ignore the misleading /context display.