Model Selector

Pick the model for the task, see the trade-off

A single default model is wrong for half your tasks — overkill for a quick reword, underpowered for a hard debug — yet the choice is hidden in settings, if it exists at all. Model Selector surfaces the engine as a per-task control: a small set of named models with their speed, cost, and strengths, switchable in one move, with a sensible default so picking is optional, not required. Consumer chat is moving the other way — ChatGPT's June 2026 redesign swapped named models for an effort slider — so the pattern's home is now power-user and developer surfaces, where the trade-off must stay visible because someone is paying for it. That drift strengthens the case, not weakens it: when the picker disappears, cost and capability visibility disappear with it.

Framing

The problem

A single default model is wrong for half your tasks — overkill for the quick ones, underpowered for the hard ones — but the choice is hidden in settings, if it exists at all, and consumer products are now removing it entirely.

The pattern

Surface the model as a per-task control — a small set of named models with their speed, cost, and strengths, switchable in one move — a control whose home is now power-user and developer surfaces, where the trade-off has to stay visible.

Why chat breaks here

Chat picks one model behind the scenes — and consumer chat is doubling down, ChatGPT's June 2026 redesign swapped named models for an effort slider — so when the picker goes, cost and capability visibility go with it.

Risks

Too many models is choice overload, and exposing raw model names without their trade-offs just moves the guesswork onto the user.

Avoid when

One model genuinely serves every task, or the audience is mainstream consumers better served by an effort dial than an engine list — the direction ChatGPT took in June 2026.

Use when

Tasks vary from trivial to hard, so a single default model is wrong for most of them — and the cost/speed/capability trade-off should be the user's to make.

DOPE evaluation

Directability: Pick the model per task or set a default — fast and cheap, or slow and capable
Observability: The active model and its trade-offs — speed, cost, context, strengths — are visible before you run
Predictability: The same model gives the same class of result; switching is explicit, never a silent swap
Explainability: Each model card states what it is good at and what it trades away, so the pick is informed

In the wild

ChatGPT · Model picker (now a reasoning slider) (OpenAI) — The picker survives but its rungs are reasoning levels, not models: Instant, Medium, High, Extra High, Pro. Model names live in the help docs — Terra and Luna are not selectable at all. No cost is shown, and ChatGPT escalates reasoning on its own unless you turn off Settings › General › Higher intelligence.
Claude · Model + effort selector (Anthropic) — Named models — Haiku, Sonnet, Opus, Fable — sit next to the send button, now paired with an effort selector running Low to Max with High marked Default. It states the trade-off plainly: more thorough answers, but slower and more tokens. Price is still nowhere in the interface.
Cursor · Model picker (Cursor) — Named models plus Auto, switchable per task — and on Teams and Enterprise, Auto now opens an Optimize For control inside the picker: Cost, Balance, Intelligence. Per-model prices still sit on the docs page and the usage dashboard, never in the picker, and Auto hides which model actually ran by default.
OpenRouter · Model catalog (OpenRouter) — Price, context length, and benchmark rank across the catalog; latency, throughput, and uptime per provider on each model page, plus a compare view and request-time routing modes — Balanced, Nitro, Exacto. The fullest trade-off surface anywhere, but it lives on browsing pages rather than inside a single pick.

FAQ

When should I use the Model Selector pattern?