You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Environment-level hidden models per provider instance (so mobile and every client respect them)
#14818
Hiding a model is a per-client preference today: providerModelPreferences[instanceId].hiddenModels lives in client settings and is applied in apps/web/src/modelSelection.ts. The server still sends every model to every client, and the mobile app does not read hidden models at all. So there is no way to hide a model for an environment as a whole. #9350 asked for this on mobile and was closed with a pointer here.
This matters when a provider instance can only actually use some models. Our team routes Claude and Codex through a shared gateway (via the instance's ANTHROPIC_BASE_URL / Codex home), and the gateway refuses certain models for certain people. T3 still lists those models on every client. Someone picks one and the turn fails with a gateway error. On desktop we work around it by having a script write client-settings.json. That only takes effect after a reload, and nothing can reach the phone or a browser client.
Proposal (small, opt-in)
Add an optional hiddenModels: string[] to a provider instance's server settings (settings.json → providerInstances.<id>). The server applies it when it builds that instance's model list (around providerModelsFromSettings in apps/server/src/provider/providerSnapshot.ts), so every client — desktop, browser and mobile — receives the filtered list.
The default is empty, so nothing changes for existing setups.
Per-client hides keep working as they do now, on top of the server list.
settings.json already hot-reloads, so an external tool can update the list without a restart.
Questions for maintainers
Should this live in the instance config, or in a top-level map keyed by instance id?
How should a thread that has already selected a now-hidden model behave? Keep it as is (like an unavailable selection today), or flag it?
settings.json only, or also a control in the provider settings UI?
If the direction and scope are acceptable, I'm happy to send a focused PR with tests covering the server snapshot and all three client types.
Environment: observed on T3 Code 0.0.42 (macOS and Linux desktop, iOS app); code references checked against main at 54084ae.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem
Hiding a model is a per-client preference today:
providerModelPreferences[instanceId].hiddenModelslives in client settings and is applied inapps/web/src/modelSelection.ts. The server still sends every model to every client, and the mobile app does not read hidden models at all. So there is no way to hide a model for an environment as a whole. #9350 asked for this on mobile and was closed with a pointer here.This matters when a provider instance can only actually use some models. Our team routes Claude and Codex through a shared gateway (via the instance's
ANTHROPIC_BASE_URL/ Codex home), and the gateway refuses certain models for certain people. T3 still lists those models on every client. Someone picks one and the turn fails with a gateway error. On desktop we work around it by having a script writeclient-settings.json. That only takes effect after a reload, and nothing can reach the phone or a browser client.Proposal (small, opt-in)
Add an optional
hiddenModels: string[]to a provider instance's server settings (settings.json→providerInstances.<id>). The server applies it when it builds that instance's model list (aroundproviderModelsFromSettingsinapps/server/src/provider/providerSnapshot.ts), so every client — desktop, browser and mobile — receives the filtered list.settings.jsonalready hot-reloads, so an external tool can update the list without a restart.Questions for maintainers
settings.jsononly, or also a control in the provider settings UI?If the direction and scope are acceptable, I'm happy to send a focused PR with tests covering the server snapshot and all three client types.
Environment: observed on T3 Code 0.0.42 (macOS and Linux desktop, iOS app); code references checked against
mainat 54084ae.All reactions