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

[fawang]

Summary

When routing to a custom model via ANTHROPIC_BASE_URL (an Anthropic-Messages-compatible gateway) whose real context window is larger than 200k, Claude Code assumes a 200k window and there is no reliable way to tell it the true size. This makes the status line and auto-compaction behave wrongly for large-window models.

Environment

• Claude Code 2.1.177 (native), macOS (arm64).
• Model id is a non-built-in string (e.g. my-gateway/big-model) served via ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN.
• The backend model's real context window is large (e.g. ~1M tokens).

Observed

• Status line shows …/200k; the statusline JSON context_window.context_window_size is 200000.
• context_window.used_percentage is computed against 200k, so resuming a session whose context exceeds 200k shows >100% and triggers auto-compaction prematurely — even though the backend supports far more.
• The [1m] suffix works for built-in model names, but there is no equivalent for an unrecognized custom/gateway model id.

Expected

A way to declare a custom model's true context window, so both the status line and the auto-compaction math use it.

Tried (and why it didn't resolve)

• Env vars around max-context / auto-compact window: I could not find a documented, working knob that makes an unrecognized custom model report or use a >200k window (the docs found were unclear/conflicting, and the status line stayed at 200k).
• [1m] suffix: applies only to known Claude model names, not custom ids.

Request (any one would solve it)

• A --model my-gateway/big-model[ctx=1048576]-style suffix for custom ids, or
• a modelOverrides / per-model contextWindow field in settings.json, or
• have gateway model discovery read a context_length / max_input_tokens field from the gateway's GET /v1/models and apply it to both the status line and compaction.

[FuturMix]

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.

[junaidtitan]

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.

[fawang]

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.

[QianQQQ]

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

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

[pcamarajr]

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.