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

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:

• https://github.com/pingdotgg/t3code/blob/main/apps/server/src/claudeModelOptions.ts
• https://github.com/pingdotgg/t3code/blob/main/apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts

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

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.