Model Management UX Exploration

[cwebster-99]

Aligning Model Management Features & UI

We have accumulated a number of overlapping concepts around how users discover, organize, and select models. Before we add more, we should step back and decide what the end-to-end experience should look like and which mechanisms we actually need.

---

What exists today

1. Auto

• Always appears at the top of the picker.

2. Pinned models

• User-curated list of models the user always wants to see at the top.
• UI: dedicated Pinned section under Auto, with inline pin/unpin affordance on every row to pin/unpin.

3. Recent models

• Automatically updated whenever the user picks a model.
• Excludes Auto and anything already pinned.
• UI: shown inside the Promoted section (mixed with featured — see below).

4. Featured models (from the models control manifest)

• Server-driven list fetched from GitHub (chat.modelsControl), split into free/paid tiers.
• Each entry has { label, featured?, minVSCodeVersion?, exists }.
• Used for upsell: featured models can render as unavailable rows with reasons (upgrade plan, update VS Code, ask admin).
• UI: surfaced in the same Promoted section as Recent.

5. Other models (collapsible)

• Everything else available from any provider group, collapsed by default.
• Grouped by provider group (vendor + user-named group) when there's more than one.
• Each group sorted: available first, then alphabetical.

6. Manage models

• Gear/toolbar entry into the full Chat Models management editor.
• Surfaced conditionally (UBB users, or as standalone action when there are no "Other" models).
• Currently there is no real differentiator for this view unless we add back hiding models.

7. Provider groups (BYOM / BYOK)

• Users can register multiple groups under a vendor (e.g. two customoai groups for two OpenAI-compatible endpoints).
• Each group becomes its own section header in Other models and contributes its own model list and per-model settings.

8. Hidden Models

• Currently removed but still under discussion
• Hidden models are removed from the model picker / Other Models section
• This is managed from the Manage Models / Language Models menu

---

What we are considering

A. Saved model configs (duplication)

A named, reusable bundle of (model + configuration values) — e.g. "Claude Sonnet — long reasoning" or "GPT-5 — deterministic" — that the user can pick from the model picker as if it were its own model.

Open questions:

• Do they appear in Pinned / Recent / Other, or get their own section? What is the default?
• Is there differentiated value of providing this feature? If this is added does it replace any other feature we already have?

---

A few tensions:

1. Promoted section is doing two jobs. It mixes user behavior (Recent) with server marketing (Featured).
2. While Pinned and Other Models have labeled sections, the Promoted section has no label
3. Pinned vs. Saved configs. If a saved config is just a model + settings, "pinning" it is the same gesture as pinning a model. Do we need both, or do pinned items just become "saved entries" (some with default config, some with overrides)?
4. Hiding vs. Other / collapsed. "Other models" is already a soft-hide (collapsed by default). Explicit hiding is a stronger version of the same idea. Do we need both, or should "Other" be the hiding affordance? Should we be more opinionated about "hiding models" by default and remove the "Other Models" section?

---

[eli-w-king]

Also considering model Search as a feature:

• Would users benefit from searching by provider, context, or thinking effort? (ex. Surfacing models from OpenRouter, with 1M context, and/or xhigh thinking)
• If we are more opinionated about hiding models, could Search replace the More models collapsable section?

[vritant24]

Small thing to add: We also don't have clear IDs for the models. Right now, a combination of various properties are used heuristically to identify models, but there isn't a clear fully-qualified-name that is unique to a vendor, a group, a model and a model config (if we want to be able to pin a specific config of a model eg: 1M context, High thinking)

[cwebster-99]

Notes from today's UBB sync:

• Model Management page should be the sole surface for model management / changes (show/hide, configs if supported) and the model picker should remain as lean as possible
• Is there still a purpose to have the Other Models section? If it is removed how will search work - does it search all models or just those in the condensed picker? How would the user know what they can search for?
• If Other Models is kept how can we polish the design?

[pwang347]

Sharing my thoughts on each of these as well (just brainstorming):

1. Auto:
I think this one we should keep it model-like as it currently is, otherwise the state can get confusing for new users. Though it could be interesting to make it more granular in the future, like picking between presets with "Cheapest", "Maximum Reasoning", etc. I'm not sure if there is demand for this, but seems like it could help for users who are looking at things from a task-based perspective.

2. Pinned Models / 3. Recent Models / 4. Featured Models / 5. Other Models:
IMO we should move the concept of featured models into the "Other Models" or "Browse Models" section and add a badge on the collapsible like [New] or something and show it until the next VS Code reload or some set time period later. The main section should only be pinned and recents unless that section is empty.

If we make a change like the above, we can probably rename the "Other Models" section to something like "Browse Models". I think we still need some way to view/select all models even if we have search. For the recents/pinned section then, I personally feel like this should not have multiple dividers but just be a single section under "Recent" / "Quick access" or some equivalent. Maybe for pinned models just keep the pin icon visible on the right. I think the recent handling logic needs to be customizable, e.g. allow a user to configure last N maybe. We should probably also not add something to recent list unless it's currently selected / a chat was actually sent (may also consider having a way to dismiss from list, though maybe not important).

6. Manage Models / 7. Provider Groups / 8. Hidden Models / 9. Model Duplication
Manage models view needs a revamp as it doesn't have a lot of value at the moment. I think it should evolve first with focus on BYOK scenarios to make that very smooth, and part of that is providing ability to hide/show models (e.g., from massive list that OpenRouter provides). For advanced controls like model duplication / creating model presets, I think it should most likely happen at this layer. For example, if the duplicated model depends on a BYOK model that is no longer available for some reason, it should show in some sort of "ghost"/warning state that makes sense to show in this more complex view but not in the model picker. There would also be more space for a better experience here. IMO the newly created models should not by default appear in the Recent models list until they are used or pinned.

Agree that expanding on search/filter would be great, though would need to think about how to retain the lightweight aspect of it.

Re: model identification, I think we need to at the very least namespace models by provider. E.g., copilot:claude-sonnet-4.6 vs. my-anthropic-byok:claude-sonnet-4.6. There's already issue today where I can't register the same model across BYOK providers sometimes and that's a problem. I wonder if we need to associate model config though as part of identification. For duplicated models we could also just require a unique model ID from the user as input and validate on that.

[eli-w-king]

Current exploration:

Screen.Recording.2026-05-22.at.5.25.16.PM.mov