AI model pickers: explain the choice and scope

Make a highlighted choice different from an applied choice.

AI Chatbot: AI Chat Assistant displays a highlighted model and a separate CHOOSE action. Genie presents a list with a checked choice and a back control. Both make selection visible, but they ask designers to resolve different commit contracts: does tapping the row apply the setting, or does it only prepare a choice for confirmation?

For a transactional sheet, keep the old active value until confirmation succeeds. A person should be able to explore a description and cancel without accidentally changing the next request. For an immediate setting, update the originating composer as soon as the new value is accepted, and make Back a navigation action rather than a misleading undo.

Avoid two competing checkmarks, one for the active value and another for a temporary candidate, without explanatory text. If applying the choice requires a network check, leave the sheet in a pending state and retain the previous value on failure. A selected border describes local intent; it does not establish that the server accepted a configuration.

Treat Auto as a policy, not another model name.

Genora gives Smart Mode its own description about choosing a model dynamically. ChatBox includes an Auto option alongside named modes and explanatory text. These presentations are useful because automatic selection is a different kind of promise from fixing a specific model for a conversation.

Explain what the policy may change and which constraints still apply. If your app can select among several services, say so in understandable terms. Do not describe the result as optimal, cheapest or most accurate unless the product has evidence and a clear definition for that claim. A routing label alone cannot substantiate it.

Keep the chosen policy separate from the model used for a completed answer. If request-level information is available, attach it to that answer rather than rewriting the conversation header as though every previous response used the latest selection. A user comparing outputs needs historical truth, not a chat transcript that changes its apparent provenance whenever a setting changes.

Do not mix models, tools and purchase gates without labels.

Chatbot App AI Assistant places model choices and tools such as image generation and PDF work in one menu. Chat AI: Ask Agent Anything uses a grid of model cards with provider labels and new-item badges. The comparison exposes a taxonomy decision: is the person selecting an engine, choosing a task, or entering another workspace?

If the menu contains all three, group them visibly. A PDF analysis tool may change the whole input flow, while a model choice may only change a setting. Giving both identical rows creates an expectation that they behave the same way. Use a task label and a destination cue for workspace changes, and a selected state for configuration.

Likewise, distinguish availability from selection. A paid badge should explain the access condition before a person commits. If an upgrade interrupts the choice, preserve the candidate and the draft message, but do not mark the option active until access is confirmed. Returning from an abandoned purchase should leave a usable composer rather than a locked configuration.

Use groups that help the decision, not only the brand inventory.

ChatSmith separates provider families into tabs and offers a Save action for the selected variant. Monica groups choices into categories such as Advanced and Reasoning. Provider navigation helps someone looking for a known name; task-oriented groups can help someone who knows the work but not the catalogue.

Neither grouping removes the need for comparable descriptions. Keep helper text parallel: supported input, a real usage constraint, and the kind of job the option serves. Do not compare one choice by speed, another by a vague superlative, and a third by an unexplained release label. The reader cannot build a consistent decision from unrelated attributes.

Preserve a valid selection when someone changes tabs merely to look around. If a chosen option becomes unavailable, disclose the change before submission and offer compatible alternatives. Silent substitution makes later comparisons difficult, particularly when a prompt or attachment was prepared for a specific capability. It also makes support reports harder to reproduce.

Keep the setting attached to the place it affects.

ChatBoost includes short descriptions in its model menu while the surrounding chat remains visible. AI Keyboard Smart Writing presents a model choice inside a keyboard-related product. This is a useful reminder that model selection is not always a chat-wide preference. It might apply to a keyboard action, a document tool, a workspace or just the next request.

Name the scope near the control. If a change applies only to new messages, say that. If it is a default for future chats, show how the current conversation differs. Avoid exposing a global-looking control that actually affects one small tool, or a local-looking sheet that changes settings across the entire account.

For longer comparison work, use ScreensDesign Pro to inspect where each picker opens and what the originating screen displays afterwards. A static menu can reveal hierarchy and labels, but the surrounding sequence is what lets you test whether the user can predict the effect of a choice.

Store configuration separately from request history.

A practical state model separates the confirmed preference, the candidate being explored, the account’s current availability and the configuration attached to each submitted request. Use stable identifiers for choices; display names can change without changing the underlying identity. Refresh availability before sending when the catalogue or entitlement is stale.

When a user changes the choice during generation, define whether it affects only the next request. Do not relabel the in-flight answer. If a newly selected option cannot accept an attached image or document, preserve the attachment and explain the incompatibility. Let the user change the option or deliberately remove the file instead of silently discarding their work.

An unavailable provider, exhausted allowance and incompatible file should not all become Model failed. Give a recoverable action for the actual condition. If fallback is offered, explain the alternative and its relevant restrictions. The interface should not invent remaining usage or hide a paid transition behind a generic retry button.

Test whether people can predict the next request.

Ask a participant to choose an option, cancel once, then submit a message. Before sending, ask which setting they believe will be used and why. Repeat after an access change, a file attachment and a new conversation. The strongest test is agreement between their prediction, the visible composer and the recorded request configuration.

Track selection completion, immediate reversals, incompatible-input failures and unexpected fallback reports. Segment by first-time and returning users rather than treating all switching as confusion. Frequent switching might be deliberate comparison. A shorter picker interaction is not automatically better if people subsequently discover that the wrong capability was active.

With assistive technology, announce the selected option and its group, expose descriptions without requiring hover, and restore focus to the originating control. Test large text with long provider names. A new badge, checkmark or information icon needs a readable label and should never become the only way to discover an access restriction.

Review the model choice contract.

Use these checks on a working build, not only on the polished reference state.

• ✓Identify whether a row applies immediately or needs confirmation.
• ✓Name the scope and preserve request-level history.
• ✓Explain Auto without promising unverified superiority.
• ✓Separate tools, fixed models and access conditions.
• ✓Keep attachments and draft text when a choice fails.
• ✓Test stale catalogues, large text and keyboard focus.

Related design decisions

The first conversation has a different job. Compare the AI chat onboarding examples when teaching what the product can do before someone encounters a model menu.

If the choice is constrained by allowance, use the usage-limit screen examples to explain what is unavailable and what changes after an upgrade without presenting payment as a technical repair.