Skip to content

[Bug]: Custom Claude model effort and Thinking selections are saved but dropped at runtime #16672

Description

@KevinXC5

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Create a custom provider instance using the Claude driver. In this setup, Magpie creates the instance and exposes codex/gpt-6.1-sol[1m], which is not in T3's bundled Claude model catalog.
  2. Declare capabilities.optionDescriptors for the custom model: an effort select (low/medium/high/xhigh/max) and a boolean thinking option. Both controls appear in the composer.
  3. Select effort High, toggle Thinking, and confirm the thread configuration saves the selected options.
  4. Start a fresh Claude CLI process and send a message. Inspect SDK query.open, the CLI arguments, and the gateway's request records.
  5. No SDK effort or CLI --effort is passed. If Claude settings specify effortLevel: "medium" for this model, the gateway receives medium even though T3 displays High.
  6. The same compilation path drops thinking=false: it does not produce alwaysThinkingEnabled:false, and the default query construction still enables adaptive thinking.

Related: #4192 / discussion #6793 concerned a missing Reasoning control. This report concerns custom models whose controls are already visible and whose choices are saved, but not applied at runtime.

Expected behavior

The Claude adapter should compile ModelSelection against the current provider instance's custom model capabilities. The selected effort should reach SDK effort / CLI --effort, and Thinking true/false should be applied using the SDK's supported options.

These options should also participate in queryIdentity, so an existing process is not reused with settings that differ from the user's selection. Preserve compatibility mappings for built-in models.

Actual behavior

The UI and thread configuration retain the selections, but the runtime compiler uses the bundled catalog. An unknown custom model therefore gets empty capabilities: effort resolves to undefined, and the Thinking option is ignored.

Evidence: effort was verified using thread configuration, SDK launch logs, CLI arguments, and gateway records. The Thinking finding is based on the runtime code path; I have not separately captured the upstream wire body for thinking=false.

Suspected cause

  • compileClaudeModelSelection(selection, catalog = BUNDLED_CLAUDE_MODEL_CATALOG) looks up capabilities in the supplied catalog.
  • ClaudeAdapterV2.makeClaudeQueryOptions calls compileClaudeModelSelection(input.modelSelection) without an instance-scoped catalog.
  • For this custom model, the effort descriptor is missing and supportsBoolean("thinking") is false, so neither SDK effort nor alwaysThinkingEnabled is generated.
  • requestThinkingSummaries checks compiledSelection.settings.alwaysThinkingEnabled !== false, and the default branch supplies adaptive thinking.
  • Other adapter calls used to construct queryIdentity also compile against the default catalog.

Code:

Please check instance-scoped catalog propagation and add regression coverage for custom model effort=high, thinking=false, and their query identities.

Impact

Major degradation or frequent failure: runtime reasoning settings differ from the visible selections, making quality and usage difficult to control.

Version or commit

0.0.46-nightly.20261006.2752. The inspected main branch also contains these calls without a custom catalog.

Environment

macOS / Apple Silicon; T3 Code Nightly desktop; Claude Code 2.1.292; Magpie v0.1.1098; custom claudeAgent provider; model codex/gpt-6.1-sol[1m].

Logs or stack traces

Saved selection: effort=high, thinking=true
SDK query.open settings: {"showThinkingSummaries":true}
No effort or alwaysThinkingEnabled field.
CLI arguments include --thinking adaptive --model codex/gpt-6.1-sol[1m]
No --effort argument.
With modelSettings effortLevel=medium, the gateway receives medium.

Workaround

Configure the model's effortLevel in Claude settings and ensure the CLI reads them. This controls the actual effort, but T3's per-thread picker still does not override it.

An explicit provider launchArgs effort or process environment override may be another fixed-effort workaround; only the settings workaround was verified here.

Activity

  1. added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 7, 2026
  2. changed the title [-][Bug]: 自定义 Claude 模型的 effort 与 Thinking 选项已保存,但没有传递到运行层[/-] [+][Bug]: Custom Claude model effort and Thinking selections are saved but dropped at runtime[/+] on Oct 7, 2026
  3. diastidean commented on Oct 7, 2026

    @diastidean

    Fast mode is affected by the same root cause: a custom model's fastMode descriptor is dropped when makeClaudeQueryOptions compiles against the bundled catalog (closed duplicate #16755). Once #16583 passes the scoped catalog, settings.fastMode should be produced; it would be worth including a custom-model fastMode: true regression case. One open question remains outside T3: whether Claude Code then forwards fast mode for a non-Claude model ID through an Anthropic-compatible proxy. I can test that end-to-end after #16583 lands.

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

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions