Model selection

Why does model selection matter?

Model selection matters because it transforms AI from a passive service into an active design choice. It makes the system adaptable to a wide range of contexts — from lightweight chats to complex agent building — while ensuring users understand and own the trade-offs behind their experience.

To understand it better, let's dive deeper.

Key takeaways

1. Stop listing models

When model selection is end-user facing, it’s not enough to list options. The design should highlight pros, cons, and benefits in context, and surface cost if it impacts usage. For example, Perplexity shows the key characteristics of models on hover. Poe goes further by exposing not only the model basics, but also social and performance signals like followers, points, and ratings.

2. Design for different expertise levels

Not every user needs the same depth of control. It differs for consumers vs prosumers, beginners vs power users. Beginners may just want a “smart default” with one-click switching, while advanced users may want to fine-tune parameters. A layered design approach can accommodate both without overwhelming either group. From TypingMind that provides you defaults to Bedrock that opens a lot of input fields.

3. Complete the loop

Model selection shouldn’t stop at choosing a model. Users should be able to adjust key parameters (e.g., temperature, presence penalty) and test outputs side by side, especially when configuring long-term flows like automations or agents. Complete the loop of selecting > configuring > testing.

4. Contextualize selection

Model selection should surface only when it meaningfully affects the task and users care about flexibility or control. Introduce it where the choice shapes outcomes, and hide it where it would add friction or noise.

Editor's notes

As a practitioner, I like to write notes — key takeaways and questions — to ask myself whenever I'm designing in the future. When designing model selection, the goal is to give users control without overwhelming them or making them feel alienated.

• Do users actually need model selection for this use case, or would it add unnecessary complexity?
• If users are less technical, are model trade-offs (speed, cost, creativity, depth) clearly explained in plain language?
• Does the UI adapt to context (lightweight for chat, more detailed for agent or flow configuration)?
• If users can select models, is there a way to test or compare them side by side?
• Are there sensible defaults and guidance for beginners, while still offering flexibility for advanced users?
• If a model becomes unavailable, does the system fail gracefully with a clear fallback path?

It’s a tangible gut-check for myself and for you to steal, if you see fit.

Future play

Today, model selection often means picking a single model for a chat, task, or agent. Increasingly, companies are moving toward multi-model orchestration where tasks are routed automatically, or domain-specific models are assigned behind the scenes. The design challenge is to make this orchestration transparent and usable, so users understand why different models are engaged without being burdened by the complexity.