Problem
A dropdown offers four names that differ by a version number and a size word. The viewer has no way to know which one answers their question better, what each costs, or whether the choice even matters for what they’re about to type.
Solution
The picker exists because the differences are real: speed, depth, price, context length, what modalities are accepted, how recent the training data is. The design failure is describing those differences in the vocabulary of the people who built the models rather than the people choosing between them. A parameter count, a codename and a point release communicate nothing to someone deciding whether to ask about a spreadsheet.
Describe each option by the job it’s good at and the price of using it. Fast and cheap for everyday questions. Slower and more careful for analysis and code. Largest context for long documents. That framing is HAX guidelines 1 and 2 in one control: make clear what the system can do, and make clear how well it can do it. A list of names does the first badly and the second not at all.
Three properties deserve to be visible in the list rather than buried in a docs page:
- Cost, on any metered plan. It is the main decision variable and hiding it makes the picker decorative.
- Context length, because it is the one hard limit that changes what tasks are possible rather than how well they go.
- Modality, because a viewer about to attach an image needs to know the fast option cannot see it before they attach it.
Switching mid-conversation is the behaviour worth designing deliberately. The new model inherits the existing transcript, which is usually what people want and occasionally surprising, because the voice changes and the earlier turns were produced by something else. A quiet marker on the turn where the switch happened costs nothing and explains a discontinuity that otherwise reads as the model losing the thread.
The default matters more than the picker does. Most people never open it, so the routing behind the default determines the experience for the majority. Automatic routing by question complexity is increasingly the answer, and it moves the design problem from choosing to explaining: when the system picked, the viewer should be able to see what it picked and override it.
Use when
The options genuinely differ in a way a viewer can act on, and the product can explain the difference in a sentence each.
Don’t use when
Two options differ by a benchmark point and nothing a person would notice. Surfacing a choice that can’t be made well is a cost with no benefit, and it invites people to believe they’re getting it wrong.
Trade-offs
Every model in the list is a decision demanded before the viewer has typed anything, and decision cost lands hardest on the newcomers who understand it least. Plain-language labels are kinder and drift from the technical truth, which frustrates the expert users most likely to open the menu. Automatic routing removes the burden and removes the agency, and it fails loudly the first time someone notices their hard question went to the cheap model. Long lists age badly: every model ever shipped wants to stay for the people who depend on it, and the menu becomes a changelog.
Checklist
- Can a non-expert tell which option to pick from the labels alone?
- Is the cost difference visible at the point of choosing?
- Is the context limit stated where it matters, or only in documentation?
- Does the list say which options accept images, audio, or files?
- What happens to the conversation when the model changes mid-thread?
- Is the switch recorded anywhere the viewer can see later?
- If routing is automatic, can the viewer see what was chosen and override it?
- How many options are in the list, and what’s the retirement rule?
- Does the default change without warning, and are people told when it does?
- Is the current selection visible without opening the menu?
Compare
ChatGPT names its tiers and puts a short capability line under each, so the menu is doing the explaining rather than deferring to documentation. Claude ties the choice to the retry control as well as the composer. Switching becomes a way to get a second opinion rather than a setting you change once. Perplexity lets the underlying model come from several vendors. The picker becomes a genuine market choice, and the product a layer over models rather than a face for one. Microsoft Copilot mostly hides the question inside the host application, betting that someone writing a document does not want to make an inference-tier decision first, which is the strongest argument against the pattern existing at all.
Related
Mode switch is the adjacent control and the two are constantly confused. Usage meter is where the cost of the expensive option shows up. Regenerate is the most useful place to offer a switch, since a second attempt with a different model is a real correction. Composer holds the control. Knowledge cutoff notice is the model property most likely to matter and least likely to be in the menu.