Overview
How might we let people assemble and edit the exact context bundle before send without guessing what the model will see?
When a turn depends on multiple sources
- ChatGPT, Claude, Cursor, and Notion-style composers where files, photos, code, or docs become turn context.
- Queries that mix several sources and need an audit of what is included before send.
- Products with a + or attach menu that can add more than one item to the same turn.
- Flows where removing a source mid-compose must be as easy as adding one.
When one attachment row is enough
- Single-file upload tools where a chip list is heavier than one attachment row.
- Products that inject hidden RAG context users cannot remove.
- Voice-first surfaces with no visual chip area, use spoken confirmation instead.
States
Design add → chip → edit → send, not only a paperclip icon.
Empty
No context chips yet. Attach lives in the composer (+ menu or equivalent) with clear source types.
Adding
The person picks a source type and chooses a file or item. Upload or resolve may still be in progress.
Chipped
Each source appears as a named chip with type cue and remove. Multiple chips stack in a scannable row.
Editing
Remove or replace chips before send. Overflow collapses with a count when the row gets long.
Blocked
A chip is still uploading or failed. Send stays disabled or warns so incomplete context is not silent.
Sent
The turn goes with the visible chip set. History should reflect what was attached, not a hidden bag.
Key UX elements
The parts that must be present for multi-source context to stay inspectable.
Offer a single menu for source types.
A + control opens files, photos, code, or drive in one place so people do not hunt three attach entry points.
Name each source with a type cue.
Filename or title plus an icon beats a generic “1 attachment” so identity stays verifiable.
Make discard first-class on every chip.
An X (or equivalent) clears that source without resetting the whole composer.
Keep all active chips visible before send.
The chip row is the audit of what the model will receive. Hide nothing critical behind overflow alone.
Block send on incomplete uploads.
Progress and per-chip errors should prevent a turn that claims sources that never finished.
Collapse only when the row cannot scan.
A +N count with expand is fine; never drop removable access to an included source.
Anti-patterns to avoid
Chips with no remove (X) or overflow that hides active context.
Duplicate menus (+, slash, drag-drop) that add the same source twice silently.
Chips that rename files so users cannot verify identity.
Sending before chips finish uploading with no disabled send state.
How products use it
| Product | Implementation |
|---|---|
| ChatGPT | + menu for files and tools; removable chips above the input. |
| Cursor | @ and attach flows that surface files/context as editable references. |
| Claude | Attach and project files represented before the turn is sent. |
| Notion AI | Page and database context selectable for a generation request. |
Real-world examples
How shipped products implement context chip management, 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
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 "Context Chip Management" AI interface design pattern.
Pattern Definition:Frequently asked questions
What is context chip management?
It is the composer pattern that adds multiple context sources through a menu and displays each as a removable chip so users can audit and edit context before send.
How does it differ from context mentions?
Mentions (@file) are typed references in the prompt. Chips are structured attachments outside the prose. Many products use both for the same underlying sources.
Should chips show upload progress?
Yes. Disable or warn on send until uploads complete, and show errors per chip so a failed file does not silently drop from the turn.
How many chips are too many?
When users cannot scan names. Cap visibly, collapse overflow with a count, and prefer project-level context for large corpora instead of dozens of one-off chips.