Repository navigation
[Bug]: Orchestrator ignores toggled-off models: orchestrator_capabilities lists them and delegate_task runs them #15716
Description
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
- In Settings → Providers, toggle off one or more models for a provider (e.g. Cursor: leave only
composer-2.5,grok-4.7,grok-4.6on; turn offgpt-5.4-nano). - Confirm they are stored as hidden in
~/.t3/userdata/client-settings.json→providerModelPreferences.cursor.hiddenModels, and that the composer model picker no longer shows them. - From an agent thread, call the T3 MCP tool
orchestrator_capabilities. - Call
delegate_taskwithtarget: { providerInstanceId: "cursor", model: "gpt-5.4-nano" }.
Expected behavior
A model toggled off in settings is not offered to or usable by orchestration, matching the composer:
orchestrator_capabilitiesomits hidden models (or at least marks them, e.g.hidden: true). Its own description says it uses "the same live catalog as the composer".delegate_taskrejects a hidden model with a clear error (optionally overridable with an explicit flag), instead of silently running it.
Actual behavior
orchestrator_capabilitiesreturns every model the provider supports and ignoreshiddenModels. For Cursor it listed 44 models when only 3 are enabled; for OpenCode it listed ~500 when 9 are enabled.- Agents pick from that list, so they choose models the user turned off. In my case an agent picked
cursor/gpt-5.4-nanoandopencode/big-pickle, both toggled off. delegate_taskaccepted and ran the hidden model. The Cursor run then failed on an account usage limit for that model, surfaced in the thread only asProvider turn failed.
Likely cause: the toggle is persisted in client settings (client-settings.json → providerModelPreferences.*.hiddenModels), while the orchestrator builds its catalog server-side from settings.json, so it never sees the preference.
Impact
Major degradation or frequent failure
Delegation is supposed to be safe to hand to agents. Today a toggle-off has no effect on what agents use, which can mean unexpected cost, usage-limit failures, or models the user deliberately excluded.
Version or commit
T3 Code (Nightly) 0.0.46-nightly.20261004.2648
Environment
macOS (Darwin 25.5, arm64), desktop app. Parent thread: Claude Agent (claude-opus-5-5), runtime mode auto. Reproduced with Cursor (cursor-agent 2026.09.15) and OpenCode 1.18.34 providers.
Logs or stack traces
# orchestrator_capabilities vs. client-settings hiddenModels (summarized)
cursor catalog: 44 models | enabled (not hidden): grok-4.7, grok-4.6, composer-2.5
opencode catalog: 500 models | enabled (not hidden): 9 opencode-go/* models
# delegate_task target {providerInstanceId: "cursor", model: "gpt-5.4-nano"} -> accepted, ran
# provider log, run.completed:
"status": "error", "error": {"message": "You've hit your usage limit ... Switch to a different model ..."}, "model": {"id": "gpt-5.4-nano"}
# thread surface: "Provider turn failed."Workaround
Before delegating, have the agent read ~/.t3/userdata/client-settings.json → providerModelPreferences.<providerInstanceId>.hiddenModels and exclude those models itself.
Related: #11031 (Android thread settings show disabled models and select one as default). Same underlying gap: hidden or disabled model preferences aren't honored outside the desktop composer.
Activity
juliusmarminge commentedon Oct 4, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the detailed counts and the provider log, @AlexisGrrd. They made the mismatch easy to confirm.
What I found
Confirmed on current
main.orchestrator_capabilitiesanddelegate_taskread the server's provider catalog, and they never see the hide toggles under Settings → Providers.ProviderModelsSection.tsx). They're stored inClientSettings.providerModelPreferences.<instance>.hiddenModels, and the composer applies them inapplyInstanceModelPreferences(apps/web/src/modelSelection.ts).userdata/client-settings.jsonover IPC, the browser keeps them in localStorage, and mobile has its own list.apps/serverdoesn't readClientSettings.OrchestratorMcpService.capabilitiesmaps every model fromproviderRegistry.getProviders.delegate_task(viaresolveTarget, whichcreate_threadsalso uses) rejects a model only when the provider no longer advertises it. That explains why you saw 44 Cursor models and about 500 OpenCode models.apps/server/src/mcp/toolkits/orchestrator/tools.tssay they use "the same live catalog as the composer." Agents read that as matching the picker, but the list they get is unfiltered.ProviderFailure.tsfor unknown provider errors. It's separate from this issue.Related but not duplicates: #11031 (mobile thread settings ignore desktop
hiddenModels) and closed #9350 (desktop hide doesn't change the environment catalog).Likely fix area
There are a few options, and choosing between them is a product decision:
A maintainer will decide on the fix direction.
nkoynov commentedon Oct 5, 2026
The unfiltered catalog also has a size cost. Some numbers from one setup: Claude (12 models), Cursor (44), and OpenCode 2 with
cursor-opencode-provider(69).orchestrator_capabilitiesreturns 61,128 bytes of JSON on a single line. OpenCode accounts for 38 KB, Cursor 15 KB and Claude 6 KB, which works out to roughly 170–550 bytes per model. With the ~500 OpenCode models in this report, it would be roughly 85–275 KB (my estimate).[showing 0 lines of 1; full output saved to …/tool-output/tool_…], and the read tool truncated the file's one 61 KB line.So filtering out hidden models, or a compact listing (ids and option ids, with details on request), would also keep the result under these limits.
Model: Claude Opus 5.5 (1M). Harness: Claude Code in T3 Code.
newink commentedon Oct 8, 2026
Another data point, from the Pi provider this time.
client-settings.json→providerModelPreferences.pi.hiddenModels, which leaves 4 visible in the picker.orchestrator_capabilitiesreturns 159,261 characters. Pi accounts for 147,772 of them, and the other six providers together for about 11K.jq, which takes a few extra calls before it can delegate anything.delegate_taskto codexgpt-5.6-lunacompleted fine.With
hiddenModelsapplied, this response would be around 12K and fit inline.T3 Code (Nightly) 0.0.46-nightly.20261005.2702, macOS arm64.
Model: Claude Opus 5.5 (1M). Harness: Claude Code in T3 Code.
t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the report. One part of this is fixed on main in #16816. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: delegate_task can still run a hidden model when its ID is supplied directly. If that part still matters to you, please open a new issue for that part only.