PTN—13

Model management

Frame model choice as a tradeoff people can reason about — fast versus thorough — not a benchmark menu.

Model pickers are where products quietly leak their org chart. A dropdown of version numbers and codenames — each one a benchmark bragging right — asks users to make an engineering decision with marketing information. Nobody outside the vendor knows what separates one alphanumeric soup from another. What people can reason about is a tradeoff: fast and cheap versus slow and thorough. Model management is the discipline of translating the roster into that language.

The translation is task-shaped, not spec-shaped. “Best for quick answers” and “takes longer, reasons deeper, costs more” are decisions a person can make in two seconds; context-window sizes and eval scores are not. And because most people should not have to decide at all, a recommended default — visibly marked — carries the load: choosing becomes optional, an escalation for the requests that deserve it rather than a toll on every message.

The choice must then stay legible. A model selected three messages ago is invisible state, and invisible state is how someone burns premium credits on small talk or trusts a fast model with a hard problem. Show the active model persistently during the conversation, not just in the picker. And when someone switches mid-task, say what carries over — the conversation history travels, but the new model has none of its predecessor’s in-flight reasoning, and pretending otherwise sets up a betrayal.

The pattern’s trajectory points toward its own disappearance: automatic routing that picks the engine per request, with manual choice as the override. That makes the honest framing more important, not less — a router is a recommendation the system makes silently, and users will only trust it if the manual picker taught them the tradeoff space first.

Anatomy

Fig. 01 — Model managementLive specimen

Choose how it thinks

What does the Marsh Creek agreement renew at?

Ask anything about your operation…Quick

A model picker framed as tradeoffs, with a marked default and the active choice visible in the conversation.

1Task-language tradeoffs. Each option states speed, depth, and cost in plain terms — model names alone decide nothing.
2Recommended default. One option is visibly marked as the default, so choosing is an override, not a prerequisite.
3Persistent active choice. The current model stays visible during the conversation, not just inside the picker.
4Switch carry-over notice. Switching mid-task states what travels — history carries, in-flight reasoning does not.

When to use

The product offers multiple models with genuinely different speed, depth, or cost profiles.
Users are choosing by superstition — always the “biggest” model, or always the default — because the picker gives them nothing to reason with.
Cost or latency differences are large enough that the wrong choice is felt, in the bill or the wait.
Power users need control while everyone else needs a decision made for them.

Design considerations

01Describe each model by what it is for — “quick answers”, “deep work” — with names as secondary labels.
02Mark a recommended default and make it good enough that most people never open the picker.
03State cost honestly at the point of choice: time, credits, or message limits, not just capability.
04Keep the active model visible in the conversation chrome, especially when it is not the default.
05On mid-task switches, say explicitly what carries over and apply the change forward cleanly.
06Prune the roster — every retired model left in the picker is a question users cannot answer.

Pitfalls

✕The benchmark menu: five codenames, no tradeoffs, and a user choosing by vibes or by whichever number is bigger.
✕Invisible model state — someone left the slow expensive option on and cannot tell why every reply crawls.
✕Silent mid-task switches (fallbacks, routing) that change the answer’s character with no acknowledgment.
✕Defaulting to the premium model for everything, converting the picker into a quiet upsell.

In the wild

Claude: The model picker pairs each option with a one-line purpose — fast for everyday tasks, more capable for complex work — instead of specs alone.
Cursor: An Auto mode routes requests to an appropriate model by default, with the manual picker as the power-user override.
v0: Model tiers are framed by size and cost tradeoff, and the active tier is visible where generation happens.