You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Let custom Claude models offer a context window choice
#13332
A custom Claude model, such as a gateway alias or a non-Anthropic model behind an Anthropic-compatible endpoint, can declare effort and fast-mode options but not a context window. Claude Code assumes 200K for model ids it does not recognize unless CLAUDE_CODE_MAX_CONTEXT_TOKENS is set, and it reads that variable once per process.
Offering two windows for one model today takes two custom rows: gateway-model, and a gateway-model-long row that a launcher script maps to the same model with a larger CLAUDE_CODE_MAX_CONTEXT_TOKENS. A hand-written contextWindow option on the base row does appear in the traits menu, but it changes nothing at launch, because scopeClaudeModelCatalog gives custom entries an empty runtime profile.
This is the Claude-side counterpart of #10538, which asks for the same choice within one Codex entry.
Proposal
An optional contextWindows list on a custom model entry, so one row offers the choice:
The Claude driver turns the list into the same contextWindow option the bundled catalog uses. The traits menu shows a Context Window group next to Reasoning, and nothing in the UI changes.
At launch, the adapter sets CLAUDE_CODE_MAX_CONTEXT_TOKENS to the chosen window. When the window has a modelSuffix, the adapter appends it to the launched model id, the way the catalog appends [1m]. The suffix is only for setups that route a longer window through a separate model name; most entries would omit it.
The chosen window becomes the context meter's capacity. A result's modelUsage also lists subagent models, so a subagent's larger window no longer replaces the lead's.
Claude Code reads the variable once per process, so a different window needs a new session. The orchestrator already restarts Claude sessions with the resume cursor when the model selection changes. The adapter refuses a turn that reaches a running session with a different window rather than running it under the old one.
Only drivers whose adapter launches the chosen window show the option. Settings decode rejects an empty list, repeated ids, two defaults, and a hand-written contextWindow option next to the list. The custom model editor keeps the list when an entry is saved.
Known limit: Claude Code applies the variable to every non-Anthropic model in the process, so a subagent on another custom model inherits the lead's window.
What exists
A branch against current main implements this in the contract, the shared reader and writer, the Claude catalog and adapter, and the settings editor, with schema, catalog and adapter tests. It is about 690 lines including tests: compare.
The screenshots below come from an isolated dev server. The Claude binary there is a local fixture that speaks the Agent SDK protocol and records its launch arguments without calling a model. In the preview, T3 launched the fixture through the real Agent SDK. The 872K choice ran the slug with its -long suffix and CLAUDE_CODE_MAX_CONTEXT_TOKENS=872000. Switching the same thread to 272K relaunched the bare slug with the resume id and 272000. None of this exercises a real provider near either limit, so it shows the plumbing, not that any model accepts 872K.
V2 and timing
The provider layer is paused for the V2 orchestrator (#8453 was closed for that reason), so I have not opened a PR. The contract and the shared reader don't depend on the orchestrator. The adapter-side mapping of window to launch environment, model id and meter capacity would move to wherever V2 launches Claude sessions, and V2's session restart would replace the current restart-on-selection-change.
Is a per-entry contextWindows list the shape you would want for custom models, or would you rather extend the catalog's runtime profile to custom entries? Should this wait for V2 and target its provider layer?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
A custom Claude model, such as a gateway alias or a non-Anthropic model behind an Anthropic-compatible endpoint, can declare effort and fast-mode options but not a context window. Claude Code assumes 200K for model ids it does not recognize unless
CLAUDE_CODE_MAX_CONTEXT_TOKENSis set, and it reads that variable once per process.Offering two windows for one model today takes two custom rows:
gateway-model, and agateway-model-longrow that a launcher script maps to the same model with a largerCLAUDE_CODE_MAX_CONTEXT_TOKENS. A hand-writtencontextWindowoption on the base row does appear in the traits menu, but it changes nothing at launch, becausescopeClaudeModelCataloggives custom entries an empty runtime profile.This is the Claude-side counterpart of #10538, which asks for the same choice within one Codex entry.
Proposal
An optional
contextWindowslist on a custom model entry, so one row offers the choice:{ "slug": "gateway-model", "contextWindows": [ { "id": "272k", "label": "272K", "tokens": 272000, "isDefault": true }, { "id": "872k", "label": "872K", "tokens": 872000, "modelSuffix": "-long" } ] }contextWindowoption the bundled catalog uses. The traits menu shows a Context Window group next to Reasoning, and nothing in the UI changes.CLAUDE_CODE_MAX_CONTEXT_TOKENSto the chosen window. When the window has amodelSuffix, the adapter appends it to the launched model id, the way the catalog appends[1m]. The suffix is only for setups that route a longer window through a separate model name; most entries would omit it.modelUsagealso lists subagent models, so a subagent's larger window no longer replaces the lead's.contextWindowoption next to the list. The custom model editor keeps the list when an entry is saved.Known limit: Claude Code applies the variable to every non-Anthropic model in the process, so a subagent on another custom model inherits the lead's window.
What exists
A branch against current
mainimplements this in the contract, the shared reader and writer, the Claude catalog and adapter, and the settings editor, with schema, catalog and adapter tests. It is about 690 lines including tests: compare.The screenshots below come from an isolated dev server. The Claude binary there is a local fixture that speaks the Agent SDK protocol and records its launch arguments without calling a model. In the preview, T3 launched the fixture through the real Agent SDK. The 872K choice ran the slug with its
-longsuffix andCLAUDE_CODE_MAX_CONTEXT_TOKENS=872000. Switching the same thread to 272K relaunched the bare slug with the resume id and272000. None of this exercises a real provider near either limit, so it shows the plumbing, not that any model accepts 872K.V2 and timing
The provider layer is paused for the V2 orchestrator (#8453 was closed for that reason), so I have not opened a PR. The contract and the shared reader don't depend on the orchestrator. The adapter-side mapping of window to launch environment, model id and meter capacity would move to wherever V2 launches Claude sessions, and V2's session restart would replace the current restart-on-selection-change.
Is a per-entry
contextWindowslist the shape you would want for custom models, or would you rather extend the catalog's runtime profile to custom entries? Should this wait for V2 and target its provider layer?🤖 Generated with Claude Code
All reactions