Context is not fuel, where more is always better. Mentions let you attach files and folders, terminal output, the git diff, past chats and browser state; open files and the selection can end up in the request too. The model's attention is a finite resource, and it is divided among everything attached: every extra block competes for the context window and shifts the focus. Assembling context is therefore a decision rather than a reflex.
The naive tactic is understandable: attach more so the agent definitely sees everything. It has the opposite effect. Half of what is attached turns out to be irrelevant, the model spends attention on it, and the needed detail drowns among similar ones. Nearly identical files are the worst of all: two variants of one module side by side force a guess. Add to that the direct cost - a large context is more expensive and slower, and in a long session it also crowds out what will actually be needed later.
The right model is context as a set of evidence. It contains exactly what is needed for the solution: the observed failure, the relevant contract, the current implementation and a verifiable expected result. Four elements, each answering its own question: what is broken, how it should behave by agreement, how it is written now, and what will tell us it is done. Everything else is noise that costs money and gets in the way. If you cannot explain why a particular file is in the request, it probably should not be there.
It helps to lay the kinds of context out in a table once: when to attach and what you are risking. Below is that map - from a file and a folder to terminal output, the git diff, a past chat and the browser. Every source has its characteristic risk, and knowing it is more useful than remembering the mention syntax: a stale copy instead of the canonical source, too large an irrelevant volume, secrets in terminal output, old assumptions from a previous conversation.
| Context | When to attach it | Risk |
|---|---|---|
| A file | There is a specific implementation or contract | A stale copy instead of the canonical source |
| A folder | You need to see the local architecture | Too large an irrelevant volume |
| The terminal | An error, a stack trace, a test result | Secrets and noise in the output |
|---|
| The git diff | Review or explanation of a change | Missing untracked and generated files |
|---|
| A past chat | You need to continue a decision already made | Old assumptions are carried forward |
|---|
| The browser | Checking the state of the interface | Sessions and sensitive page data |
|---|
Two sources deserve separate caution. Terminal output often contains environment variables, tokens and internal addresses - attaching it in full hands that to the model and into the transcript. Browser context carries session state: the open page may be authenticated, and along with the markup the request will include what you did not intend to show. In both cases it is safer to attach a fragment rather than everything: diagnosing an error needs the stack and the message, not the whole history of the output.
For a large-scale search there is a cheaper path than attaching half the repository. A separate Explore subagent works in its own context window and returns a summary without cluttering the main conversation with raw results. And an exact symbol or error string is found by the agent through a fast repository search anyway. That is a division of labor: a wide survey goes to a separate context, an exact hit goes to search, and only the conclusion reaches the main conversation.
A minimal set does not mean a thin one. If the canonical source drops out of the evidence - an interface, a schema, a contract - the agent will not stop; it will reconstruct it from indirect signs and write code against its own reconstruction. The sign of this mistake is recognizable: a freshly invented field name, a custom error format or a duplicate of an existing function shows up in the diff. The cure is not more volume but a substitution: attach one correct file instead of ten neighboring ones.
Beyond mentions there are two more input channels. An image can be dragged into the prompt input or pasted from the clipboard - that is how a mockup, a screenshot of the interface or a screen with an error gets into the request instead of being retyped by hand. A prompt can also be dictated by voice through the microphone in the same input; the transcription is worth rereading before sending, because file and function names are what it handles worst. Both channels spend the same window that files do. How full it is shows in the ring next to the prompt input, and a click opens a breakdown by category. When the window gets close to full, the older part of the conversation is compressed into a summary: room is freed, but the details of earlier steps remain only as a retelling.
A separate line of spending is the length of the conversation. Context accumulates on its own: every answer, every attached fragment and every rejected hypothesis stays in the history and keeps influencing the next step. By the middle of a large task a noticeable part of the window is occupied by what is already wrong, and the agent honestly relies on it alongside the fresh material. It is cheaper to open a new conversation and gather the evidence again than to explain which earlier conclusions no longer hold.
The engineering conclusion is short: attach the minimal set sufficient for the solution. Such a set is easier to assemble than it seems if you ask yourself one question: what exactly will prove the task is solved. The answer almost always names two or three specific sources - and that is the context you need.
The typical failures with context are predictable. Attaching the whole repository just in case and getting blurred attention and an extra bill. Attaching a stale copy of a file instead of the canonical source. Handing terminal output with secrets into the request. And continuing a long conversation with old assumptions instead of starting a new one with a clean set of evidence.