[Feature]: Expose reasoning effort for custom Claude models

[IsraelAraujo70]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

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

• I would be open to helping implement this.

[makeavish]

Confirmed on T3 Code 0.0.33 with Claude Code 2.1.229 and OpenCodex 2.14.1: custom gpt-5.6-sol works through ANTHROPIC_BASE_URL, but the Reasoning picker is missing, so effort can’t be changed per thread. Gateway defaults or separate model aliases are the only practical workaround. Since #4194 already validated SDK-based discovery for low through max, could the V2 implementation be prioritized once #2829 lands?

[mimen]

@juliusmarminge I saw you mentioned on #4194 that the custom Claude reasoning feature should be reopened after the orchestration V2 migration. I just put up #8964 to do that. This is my first attempt at contribution -- would you be open to reviewing it when you have time?

[juliusmarminge]

Resolved by merged #9807 (custom model names and option descriptors, including effort).