Foundry: Opus 5 / Fable 5 context window falls back to 200k instead of 1M (missing native_1m_3p in model catalog)

Summary

When using Claude Code with Microsoft Foundry as the provider, claude-opus-5 and claude-fable-5 are treated as having a 200,000 token context window instead of their native 1M. claude-sonnet-5 is not affected.

This inflates the context indicator by ~5x and, more importantly, makes auto-compact fire at roughly 160k tokens instead of ~800k — silently discarding most of the available context window.

Environment

• Claude Code VS Code extension 2.1.246-darwin-arm64 (bundled native binary)
• Platform: macOS, darwin arm64
• Provider: Microsoft Foundry

CLAUDE_CODE_USE_FOUNDRY=1
ANTHROPIC_FOUNDRY_BASE_URL=https://<resource>.services.ai.azure.com/anthropic
ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5
ANTHROPIC_DEFAULT_FABLE_MODEL=claude-fable-5
ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5

Evidence

Measured from a real session transcript (input_tokens + cache_read_input_tokens + cache_creation_input_tokens of the last assistant turn):

| | |
|---|---|
| Actual context in use | 139,326 tokens |
| Indicator displayed | ~70% |
| 139,326 / 200,000 | 69.7% — matches what is displayed |
| 139,326 / 1,000,000 | 13.9% — what should be displayed |

Reproduced with both claude-fable-5 and claude-opus-5; switching between them did not change the behaviour.

Root cause

The bundled model catalog declares both models with a native 1M window and correct Foundry provider ids:

id:"claude-fable-5", provider_ids:{ /* ... */ foundry:"claude-fable-5" /* ... */ },
context:{ window:1e6, native_1m:true, supports_1m_beta:true }

id:"claude-opus-5", provider_ids:{ /* ... */ foundry:"claude-opus-5" /* ... */ },
context:{ window:1e6, native_1m:true, supports_1m_beta:true, supports_1m_suffix:true }

However, the third-party provider gate does not read native_1m / window. It requires a separate native_1m_3p field:

function tM(provider, ctx){
  let n = ctx?.native_1m_3p;
  switch(provider){
    case "bedrock": case "vertex": case "foundry":
      return n?.[provider] === true;
    case "gateway":
      return n?.bedrock === true && n?.vertex === true && n?.foundry === true;
    default:
      return false;
  }
}

native_1m_3p is absent from the claude-opus-5, claude-fable-5 and claude-mythos-5 entries. Searching the entire catalog, exactly one model carries it:

// claude-sonnet-5 — the only entry with the flag
context:{ window:1e6, native_1m:true, native_1m_3p:{ bedrock:true, vertex:true, foundry:true } }

So for Foundry, n?.["foundry"] evaluates to undefined, the check fails, the resolver falls through, and it returns the default constant wE = 200000.

First-party is unaffected because it short-circuits earlier in the same function (if (provider === "firstParty" && ...) return true).

Impact

This is not only a display issue. The resolved window also feeds the remaining-capacity computation (window - max_output_tokens) used to trigger auto-compact, so long sessions compact roughly 5x earlier than they should.

Workaround (and why it is awkward)

CLAUDE_CODE_MAX_CONTEXT_TOKENS on its own is ignored for any model id starting with claude-:

if (r !== undefined && r > 0 && !P(X(e)).startsWith("claude-")) return r;

It is only honoured through a path that additionally requires DISABLE_COMPACT:

function OE(){
  if (c.DISABLE_COMPACT) {
    let e = c.CLAUDE_CODE_MAX_CONTEXT_TOKENS;
    if (e !== undefined && e > 0) return e;
  }
}

so the only override that works today is:

export DISABLE_COMPACT=1
export CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000

which trades the bug for losing auto-compact entirely.

Suggested fix

1. Add native_1m_3p:{ bedrock:true, vertex:true, foundry:true } to the claude-opus-5, claude-fable-5 and claude-mythos-5 catalog entries (mirroring claude-sonnet-5), limited to whichever providers actually serve 1M.
2. Optionally, honour CLAUDE_CODE_MAX_CONTEXT_TOKENS for claude-* models without requiring DISABLE_COMPACT, so there is a non-destructive escape hatch when the catalog lags a model launch.