Overview
How might we let people arm search, code, image, and connectors before send without turning the composer into a settings panel?
When mode changes what the model can do
- ChatGPT, Claude, Perplexity, and Gemini where search, image, code, or connectors change the next turn.
- Products with multiple capabilities that should be visible before send, not discovered after a failed answer.
- Bar chips when mode is the product (Perplexity Search vs Computer); + menus when most users should just type.
- Any composer where silent tool use would surprise people about cost, latency, or data leaving the thread.
When one capability is the whole product
- Single-capability products where a tool picker is empty ceremony.
- Agent flows that must choose tools automatically and only need post-hoc disclosure.
- Mobile composers where a permanent row of mode chips crowds the send control.
States
Design the pre-send tool contract, not only the + menu icon.
Default
No tools armed. The composer reads as plain chat until the person opens the menu or taps a chip.
Browsing
The + menu or tool flyout is open. Search, attach, image, and connectors appear as peer choices.
Armed
One tool or mode is on for this turn. A single chip (or menu checkmark) shows what will run when they send.
Composing
Prompt text and the active tool coexist. Placeholder copy can shift to match the mode (search, image, think).
Sending
The message goes out with the selected tool. Tool choice travels with the prompt, not as a post-hoc guess.
Running
The model uses the armed tool. Status in the thread matches the chip that was visible pre-send.
Key UX elements
The parts that must be present for tool choice to feel intentional.
Group capabilities in one discoverable entry.
A + menu or tools button beats burying search, attach, and image in separate settings.
Show the one armed tool before send.
A single removable chip names the active mode. Switching tools replaces the chip instead of stacking more.
Switch or turn off — don’t stack modes.
Pick another menu row to switch. Checkmark or second tap turns the current tool off. No pile of simultaneous mode chips.
Pick a sane baseline per product.
Claude defaults web search on; Perplexity defaults Search. State the default in copy when it affects cost or latency.
Use outcome language, not infra names.
Search, Create image, and Thinking beat internal tool IDs. Note when a mode is slower or uses credits.
Treat modes as exclusive when they collide.
Search, Think, and Image should replace each other. Don’t let incompatible modes run in parallel.
Anti-patterns to avoid
Hidden tools with no discoverable entry until after the user fails.
Stacking multiple exclusive modes as simultaneous chips (Search + Think + Image all on).
Active tools with no removable chip, checkmark, or clear off state.
Mode labels that change cost or latency without saying so.
How products use it
| Product | Implementation |
|---|---|
| ChatGPT | + menu for attach and modes; picking Search, Think, or Image replaces the prior mode with one chip. |
| Claude | Web search toggles with a checkmark in the + menu; skills and attach share the same entry point. |
| Perplexity | Primary mode chips (Search, Computer) are exclusive; + covers uploads and connectors. |
| Gemini | + menu leads with Drive; Deep research and creation tools in flyouts. |
Real-world examples
How shipped products implement tool switching in composer, from our teardown guides.
ChatGPTChatGPT composer UX: input bar, tools & voice design
Design the composer
ClaudeClaude composer UX: model picker, skills & attachments
Design the composer
DeepSeekDeepSeek composer UX: DeepThink, Search & modes
Design the composer
GeminiGemini composer UX: tools, Drive & thinking modes
Design the composer
Google AI ModeGoogle AI Mode composer UX: Canvas, Create & Lens
Design the composer
GrokGrok composer UX: skills, models & voice input
Design the composer
LovableLovable composer UX: Build, Plan & templates
Design the composer
ManusManus composer UX: assign tasks, modes & agent tiers
Design the composer
PerplexityPerplexity composer UX: search modes & connectors
Design the composer
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Tool Switching in Composer" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is tool switching in an AI composer?
Tool switching lets users pick which capability the model may use on the next message (web search, thinking, image generation) usually via a + menu. Modes are typically exclusive: picking one replaces the previous.
Should tools live in the bar or behind a menu?
Put mode chips in the bar when mode is the product (research depth). Use a + menu when most users should just type. Show at most one active mode chip, not a pile of every tool.
How is tool switching different from model selection?
Tool switching chooses capabilities for a turn. Model selection chooses which model or tier runs. Products often expose both; conflating them in one unlabeled control confuses cost and behavior.
How do I show which tools are active?
Use a checkmark in the menu plus one removable chip in the composer. Silent tool activation without UI is a trust failure; stacking exclusive modes as many chips is also wrong.