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
desktop: Settings Models tab is missing the provider-level visibility toggle #45225
In Settings → Models, models are grouped by provider and each model has its own visibility switch. If a provider has a long list, I have to toggle them one by one.
There used to be a master switch on the provider row that turned all of that provider's models on or off. I still see that switch in the model picker's Manage models dialog, but it is missing from the Settings page.
The Settings tab was added in #29689 without this control. The manage dialog still has it (packages/app/src/providers/models/manage.tsx). I think Settings just never got the same header switch.
Plugins
Not relevant. This is a desktop Settings UI issue.
OpenCode version
0.0.0-beta-18269
Steps to reproduce
Open OpenCode Desktop.
Open Settings → Models.
Expand a provider with many models, e.g. DeepSeek.
Try to hide or show every model from that provider.
Expected: the provider row has a master switch, same as Manage models. Turning it off hides every model in that group from the model picker. Turning it on shows them all.
Actual: only per-model switches are available on the Settings page. I have to click each one.
Workaround: I can still use the master switch from the model picker → Manage models.
Suggested fix: reuse the existing providerVisible / setProviderVisibility logic from packages/app/src/providers/models/manage.tsx in packages/app/src/settings/models/models.tsx. Put the switch on the provider header and use the existing i18n key dialog.model.manage.provider.toggle. No backend or visibility-storage change should be needed.
Since #45267 was closed, would it be OK if I picked this up?
I noticed #51479 is already addressing the bulk visibility update, so I’d avoid duplicating that work and build the Settings control on top of the resulting model controller API.
Would you prefer the provider switch used in Manage models, or the existing Enable all / Disable all action pattern? Also, should I wait for #51479 to merge before opening the implementation PR?
Thanks for the detailed report and the pointer to the code! You're asking for the provider-level master switch from Manage models to be added to the provider headers in Settings → Models, so you can show or hide all of a provider's models at once.
You're right about the gap: the Manage models dialog puts a switch on each provider header, but the Settings page only has per-model switches. As far as I can tell, the Settings page never had this switch, so we're tracking it as an improvement rather than a regression. Maintainers will consider it. In the meantime, the master switch in the model picker → Manage models still works.
Activity
nightire commentedon Aug 26, 2026
@Hona Can I submit a PR to fix this small issue?
Hona commentedon Aug 26, 2026
Yes sure!
Nice it's on v2
CristianJ12 commentedon Oct 6, 2026
Since #45267 was closed, would it be OK if I picked this up?
I noticed #51479 is already addressing the bulk visibility update, so I’d avoid duplicating that work and build the Settings control on top of the resulting model controller API.
Would you prefer the provider switch used in Manage models, or the existing Enable all / Disable all action pattern? Also, should I wait for #51479 to merge before opening the implementation PR?
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report and the pointer to the code! You're asking for the provider-level master switch from Manage models to be added to the provider headers in Settings → Models, so you can show or hide all of a provider's models at once.
You're right about the gap: the Manage models dialog puts a switch on each provider header, but the Settings page only has per-model switches. As far as I can tell, the Settings page never had this switch, so we're tracking it as an improvement rather than a regression. Maintainers will consider it. In the meantime, the master switch in the model picker → Manage models still works.