Skip to content

[Feature]: Expose reasoning effort for custom Claude models #4192

Description

@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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions