What task are you trying to do?

Attach an image to the assistant so it can read and respond to it.

What do you do today?

When the currently selected model does not support image input, a toast appears: "Current model does not support images. Switch to a model that supports images, then re-add." The toast includes a "Select model" button that opens the model selector.

The selector shows a long list of models with no visible indication of which ones support images. The only way to tell is to hover over each model and read the tooltip, which shows "Supports: text" or "Supports: text, image." Non-technical users do not hover to inspect tooltips; they scan the list visually and guess.

So the flow becomes: toast appears → click "Select model" → stare at a list of indistinguishable models → give up or pick randomly. The toast tells the user what to do, but the selector gives them no actionable next step.

What would a good result look like?

Models that support image input show a visible tag directly in the selector list, next to the model name. The user can immediately scan the list, spot the tagged models, pick one, and return to re-attach the image. No hovering, no guessing.

Specifically:

• Tag text: "图片" (zh) / "Image" (en)
• Tag color: brand orange, extending the existing Tag component with a variant="primary" prop
• Shown globally in all model selector contexts, not only when triggered from the toast
• Max 2 tags per list item
• Tag priority: free > image > latest
• Overflow tags hidden from the list item but still shown in the tooltip

What is not in scope:

• No change to toast copy
• No automatic re-adding of rejected images after model switch
• No reordering or filtering of the model list by capability
• No additional capability tags (PDF, audio, video, reasoning)

Which audience does this matter to most?

Both

Extra context

Real user feedback: A non-technical user hit this exact flow. The toast appeared, they clicked "Select model," and then had no idea which model to pick. The problem is not the lack of a toast; it is that the selector does not surface capability information at the list level.

Related work: Issue #100 originally specified model-aware attachment routing. PR #107 implemented the routing and toast but left capability visibility in the selector unresolved.

Implementation notes:

• Reuse existing modelSupportsInput utility for consistency with backend routing logic
• Extend the shared Tag UI component with a variant="primary" prop
• Update the model selector list rendering to conditionally show the image tag
• Add i18n key model.tag.image