Custom model via ANTHROPIC_BASE_URL: no way to declare a context window >200k (status line & auto-compaction assume 200k)

The core problem is that Claude Code falls back to a 200 k context window for any model ID it doesn't recognize, and there's no override knob for custom/gateway models.

Two practical workarounds while this is open:

1. Model metadata via GET /v1/models
If your gateway exposes an OpenAI-compatible GET /v1/models endpoint that returns context_length (or the Anthropic-style max_input_tokens) per model, some tools already read and respect that value. Worth checking whether Claude Code issues a models-list call on startup — if it does, ensuring your gateway returns the correct context size there may fix the status line.

2. Gateway-level model aliasing
Some API gateways let you map a custom model ID to a known upstream model name and override metadata fields like context window, max output tokens, and pricing. The gateway advertises the model under the alias your client expects while routing to whatever backend actually serves it. This way the client sees the correct context size without needing a code change.

For reference, I put together a short integration guide covering how OpenAI-compatible gateways handle model metadata passthrough and aliasing for tools like Claude Code: https://futurmix.ai/docs/integration-guide

Disclosure: I work on FuturMix, an OpenAI-compatible API gateway. I ran into this exact 200 k assumption while routing Claude Code through a custom endpoint and the aliasing approach above was how I worked around it. Sharing in case it helps; feedback welcome.

The modelOverrides/contextWindow field in settings.json request is the right fix — without it, both the status line and the compaction threshold are wrong for any non-enumerated model, and there's no clean workaround at the CC configuration layer.

One thing that helps while waiting for that: instead of trying to raise CC's assumed 200k limit (not currently possible without the feature you're requesting), you can keep the JSONL thin enough that CC's compaction trigger never fires in the first place. That's what cozempic's guard mode does — it monitors session token count and prunes the JSONL at a configurable threshold (stripping verbatim tool outputs from older turns, keeping conclusions/summaries), so the session stays well under the 200k mark CC watches. If the JSONL never reaches the 200k auto-compact threshold, the premature compaction that's been frustrating you stops happening.

pipx install cozempic — the guard runs as a daemon, prunes in the background, and reloads the session. You can tune the threshold so pruning fires early (say 120–140k tokens) and cleanly, rather than having CC's compaction cut in at 200k unexpectedly.

Honest limits: this is a workaround, not the fix you need. It prevents premature compaction, but it doesn't give you a true 1M-token session — the JSONL stays small. If you legitimately need to carry 500k+ tokens of conversation history in a single session, only the contextWindow override feature you're proposing will get you there. The status line denominator will also still read 200k until Anthropic fixes the detection path.

Confirming the modelOverrides / per-model contextWindow setting (option 2 in the issue) is the fix I'd want — the CLI suffix would also work, but a settings field is cleaner for persistent multi-model setups.

One data point against the gateway-discovery route (option 3): I checked a LiteLLM-based gateway's GET /v1/models and the model objects carry only id, object, created, owned_by — no context_length / max_input_tokens. So for gateways like this there's nothing for CC to read even if it did honor it; the explicit contextWindow override is the only thing that would actually work. Thanks @FuturMix / @junaidtitan for the workarounds.

You can change your ANTHROPIC_MODEL with the suffix [1m].

example: "ANTHROPIC_MODEL": "glm-5.2[1m]"

A data point that extends this beyond custom/unrecognized model ids: the same 200k cap happens with a recognized, built-in model (claude-opus-4-8) when it's routed through a local Anthropic-Messages proxy via ANTHROPIC_BASE_URL.

Setup: Claude Code 2.1.183 (native, macOS arm64), Max plan, opus[1m] selected. The proxy forwards to api.anthropic.com and preserves auth + the anthropic-beta/anthropic-version headers. Direct claude → 1M. Same config through the proxy → 200k.

Root cause, confirmed from the proxy's inbound-request log: when routed through the custom base URL, Claude Code's own anthropic-beta header omits context-1m-2025-08-07 entirely. On /v1/messages/count_tokens:

anthropic-beta: claude-code-20250219,oauth-2025-04-20,interleaved-thinking-2025-05-14,
                context-management-2025-06-27,token-counting-2024-11-01

and on /v1/messages:

...,prompt-caching-scope-2026-01-05,mid-conversation-system-2026-04-07,
extended-cache-ttl-2025-04-11,advisor-tool-2026-03-01,effort-2025-11-24,structured-outputs-2025-12-15

— still no context-1m. So the proxy never even gets the chance to forward it; the header is dropped client-side. CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 alone did not lift the 200k cap.

What worked (matching @QianQQQ's suggestion above): forcing the suffix via env rather than relying on the saved /model picker selection —

ANTHROPIC_MODEL='claude-opus-4-8[1m]' claude   # behind the proxy

With this, Claude Code does send context-1m-2025-08-07 and the 1M window activates through the proxy.

So for recognized models there is a working env workaround, but the saved opus[1m] picker selection does not survive a custom ANTHROPIC_BASE_URL — which I think reinforces the case for a persistent settings field (option 2: a per-model contextWindow in modelOverrides), since the env hack is brittle for multi-model setups and is easy to forget when launching via a wrapper.

@pcamarajr — this is a useful extension of the original report. The implication is that the 200k fallback isn't just about "unrecognized model IDs" — it's about CC's ability to resolve the model at dispatch time, and local proxy routing can break that even for fully recognized model strings.

What's likely happening: CC builds the effective context window from a lookup table keyed on model ID at the point it receives the API response. When a local proxy mediates the connection, the model ID in the response may not arrive in the form CC's lookup expects (routing header, response body format, proxy normalization), so it falls through to the 200k default even for claude-opus-4-8.

The ANTHROPIC_BASE_URL-level fix (a modelOverrides / contextWindow settings field) is still the right native ask. For the immediate problem with cozempic: --context-window flag or COZEMPIC_CONTEXT_WINDOW env var tells cozempic the actual window size independently of what CC thinks — cozempic current --context-window 1000000 gives you accurate session stats even when CC's own measurement is off. Doesn't fix CC's compaction threshold, but at least the per-session diagnostic is correct.

<img width="214" height="96" alt="Image" src="https://github.com/user-attachments/assets/1beaeb58-70f2-411c-8809-1388c5b3f12d" /> in settings.json ad [1m] to get 1 million context window. Working for me

+1

Same issue with custom model (Qwen3.7-Max-DogFooding) via ANTHROPIC_BASE_URL.

With DISABLE_COMPACT=1 + CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000: context window is 1M, but /compact doesn't work.
With DISABLE_COMPACT=0: context window drops to 200k, /compact works but 200k is too small.

The CLAUDE_CODE_MAX_CONTEXT_TOKENS override only takes effect in the DISABLE_COMPACT=1 code path. A per-model contextWindow field in settings would be the cleanest fix.

Can confirm this appears to be fixed in Claude Code v2.1.193.

Setup:

• Custom model via ANTHROPIC_BASE_URL
• DISABLE_COMPACT=0
• CLAUDE_CODE_MAX_CONTEXT_TOKENS=1000000
• CLAUDE_CODE_DISABLE_1M_CONTEXT=0

Result:
/context now correctly shows 131.9k/1m tokens — the 1M context window is honored even with compact enabled, and the model name does not need a [1m] suffix.

The previous behavior (200k cap when DISABLE_COMPACT=0) is no longer reproducible.

Could someone from the maintainers verify and close this issue if confirmed?

Thanks!

Confirmed this is still reproducible in Claude Code 2.1.218 on macOS arm64, specifically with gateway model discovery enabled.

The gateway's Anthropic-format GET /v1/models response includes capability metadata for the discovered custom model:

{
  "display_name": "GPT 5.6 Sol",
  "max_input_tokens": 372000,
  "max_tokens": 128000
}

(The gateway's 372000 value is stale in this particular test; the live upstream catalog says 272000. The important point for this bug is that the value is present and is not 200000.)

Claude Code successfully discovers and uses the model, but /context and the status-line payload still report a 200000 context window. Setting CLAUDE_CODE_MAX_CONTEXT_TOKENS=272000 makes the custom model use the correct window, confirming that the 200K value is the client fallback rather than anything reported by the gateway.

The shipped 2.1.218 bundle appears to already parse discovered model objects with this shape:

{
  id: string,
  max_input_tokens?: number,
  max_tokens?: number
}

However, the context-window resolution path does not consult the discovered max_input_tokens; unknown models fall through to 200000. The discovered max_tokens field does appear to have a consumer in output-token limit resolution.

So gateway discovery is working and the required metadata is already available. The missing behavior is applying discovered max_input_tokens to /context, status-line percentages, and auto-compaction. This seems preferable to requiring a global environment override, especially for gateways exposing models with different limits.

A second reproducible symptom shows why the environment-variable workaround is insufficient when model discovery is used.

With CLAUDE_CODE_MAX_CONTEXT_TOKENS=272000:

1. Start Claude Code explicitly with the raw custom ID gpt-5.6-sol.
2. /context correctly reports a 272K window.
3. Use /model to switch to discovered gpt-5.3-codex-spark; it reports 200K.
4. Use /model to switch back to discovered GPT-5.6 Sol; it now also reports 200K rather than returning to 272K.

The gateway makes non-Claude models discoverable using reversible Claude-shaped IDs, for example:

gpt-5.6-sol          -> claude-fable-5-dd-los-6.5-tpg
gpt-5.3-codex-spark  -> claude-fable-5-dd-kraps-xedoc-3.5-tpg

It decodes those aliases back to the real IDs for routing. Claude Code's picker stores/selects the discovered alias, while CLAUDE_CODE_MAX_CONTEXT_TOKENS is only applied to active model IDs that do not canonicalize to a claude-* name. Therefore:

• Initial raw gpt-5.6-sol: override applies, 272K.
• Picker-selected Claude-shaped alias: override is skipped, 200K fallback.
• Switching back through the picker selects the alias again, so the fallback persists.

This reinforces that the durable fix is to use each discovered model's max_input_tokens. A global override cannot represent heterogeneous gateway models, and even its applicability changes depending on whether the same model was selected by raw ID or through discovery.

Correction to my previous follow-up: I have now disproved the gateway-alias hypothesis.

I patched the test gateway to disable model-list cloaking and verified that its Anthropic-format /v1/models response contains raw IDs only (gpt-5.6-sol, gpt-5.6-terra, etc.), with zero claude-fable-5-dd-* aliases. The active Claude Code process still had:

CLAUDE_CODE_MAX_CONTEXT_TOKENS=272000

The persisted session transcript also records the actual response model sequence using raw IDs throughout:

gpt-5.6-sol
gpt-5.3-codex-spark
gpt-5.6-sol

Despite that, the behavior remains:

1. Start with claude --model gpt-5.6-sol: context window is 272K.
2. Switch models during the session.
3. Switch back to raw gpt-5.6-sol: context window is now 200K.

So this is a Claude Code model-switch state/cache bug, not a consequence of gateway ID rewriting. The custom context override is applied for the initial CLI-selected model but is not reliably reapplied after an in-session model transition, even when the restored model ID is exactly the same raw non-Claude ID and the environment variable remains present.

Version: Claude Code 2.1.218, macOS arm64.