Before submitting
Area
apps/server, apps/web
Problem or use case
T3 Code supports Claude provider instances with custom environment variables, base URLs, and model IDs. This makes it possible to use Claude Code through a Claude-compatible gateway that exposes non-Anthropic model IDs, for example an OpenAI-compatible reasoning model routed through an Anthropic Messages API adapter.
These custom Claude models currently receive empty capabilities. As a result, the model can be selected and used, but the composer does not show the Reasoning control that built-in Claude models receive. Users cannot choose the Claude Code --effort level for that session even though the installed Claude CLI accepts low, medium, high, xhigh, and max.
There is a second issue for this use case: the current effort normalization treats every unknown model as a legacy built-in Claude model and converts xhigh to max. A custom backend that supports xhigh therefore cannot receive the selected value unchanged.
Proposed solution
Give custom Claude models a small default capability descriptor for the CLI-supported reasoning levels:
- Low
- Medium
- High (default)
- Extra High
- Max
Keep the existing compatibility mapping for known built-in Claude models, but preserve xhigh for unknown/custom model IDs.
Why this matters
Custom Claude provider instances are already sufficient to route Claude Code through compatible gateways. Exposing the existing effort control makes those instances usable with reasoning models without adding a new provider type or provider-specific UI.
Smallest useful scope
Only change the default capabilities assigned to custom Claude models and the xhigh normalization guard. No new settings schema or frontend component is needed because the existing generic provider-option UI already renders the descriptor.
Alternatives considered
- Configure effort globally in the gateway. This prevents per-session selection and can silently override the user's choice.
- Encode effort into separate model aliases. This duplicates models and still does not expose the native Claude Code session control.
- Add per-model capability editing to Settings. That is substantially broader than this use case.
Risks or tradeoffs
Some Claude-compatible backends may ignore or reject an effort value. The values proposed here are the levels advertised by the Claude CLI itself, and no value outside that CLI contract is introduced.
Examples or references
The equivalent pattern already exists for custom Codex models, which receive default reasoning capabilities instead of an empty capability set.
Contribution
Before submitting
Area
apps/server, apps/web
Problem or use case
T3 Code supports Claude provider instances with custom environment variables, base URLs, and model IDs. This makes it possible to use Claude Code through a Claude-compatible gateway that exposes non-Anthropic model IDs, for example an OpenAI-compatible reasoning model routed through an Anthropic Messages API adapter.
These custom Claude models currently receive empty capabilities. As a result, the model can be selected and used, but the composer does not show the Reasoning control that built-in Claude models receive. Users cannot choose the Claude Code
--effortlevel for that session even though the installed Claude CLI acceptslow,medium,high,xhigh, andmax.There is a second issue for this use case: the current effort normalization treats every unknown model as a legacy built-in Claude model and converts
xhightomax. A custom backend that supportsxhightherefore cannot receive the selected value unchanged.Proposed solution
Give custom Claude models a small default capability descriptor for the CLI-supported reasoning levels:
Keep the existing compatibility mapping for known built-in Claude models, but preserve
xhighfor unknown/custom model IDs.Why this matters
Custom Claude provider instances are already sufficient to route Claude Code through compatible gateways. Exposing the existing effort control makes those instances usable with reasoning models without adding a new provider type or provider-specific UI.
Smallest useful scope
Only change the default capabilities assigned to custom Claude models and the
xhighnormalization guard. No new settings schema or frontend component is needed because the existing generic provider-option UI already renders the descriptor.Alternatives considered
Risks or tradeoffs
Some Claude-compatible backends may ignore or reject an effort value. The values proposed here are the levels advertised by the Claude CLI itself, and no value outside that CLI contract is introduced.
Examples or references
The equivalent pattern already exists for custom Codex models, which receive default reasoning capabilities instead of an empty capability set.
Contribution