Before submitting
Area
apps/server
Steps to reproduce
- 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.
- 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.
- Select effort High, toggle Thinking, and confirm the thread configuration saves the selected options.
- Start a fresh Claude CLI process and send a message. Inspect SDK
query.open, the CLI arguments, and the gateway's request records.
- 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.
- 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.
Before submitting
Area
apps/server
Steps to reproduce
codex/gpt-6.1-sol[1m], which is not in T3's bundled Claude model catalog.capabilities.optionDescriptorsfor the custom model: aneffortselect (low/medium/high/xhigh/max) and a booleanthinkingoption. Both controls appear in the composer.query.open, the CLI arguments, and the gateway's request records.effortor CLI--effortis passed. If Claude settings specifyeffortLevel: "medium"for this model, the gateway receives medium even though T3 displays High.thinking=false: it does not producealwaysThinkingEnabled: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
ModelSelectionagainst the current provider instance's custom model capabilities. The selected effort should reach SDKeffort/ 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.makeClaudeQueryOptionscallscompileClaudeModelSelection(input.modelSelection)without an instance-scoped catalog.supportsBoolean("thinking")is false, so neither SDK effort noralwaysThinkingEnabledis generated.requestThinkingSummariescheckscompiledSelection.settings.alwaysThinkingEnabled !== false, and the default branch supplies adaptive thinking.queryIdentityalso 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
claudeAgentprovider; modelcodex/gpt-6.1-sol[1m].Logs or stack traces
Workaround
Configure the model's
effortLevelin 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
launchArgseffort or process environment override may be another fixed-effort workaround; only the settings workaround was verified here.