Context is not the context window
One is what the agent knows that is relevant. The other is a container. Confusing them produces sessions that are full and useless.
This is the distinction most people skip, and almost every context-management mistake traces back to it.
- Context window: the container. Measured in tokens. Fixed by the model.
- Context: the relevant information the agent actually has right now. Not measurable in tokens, because relevance is not a property of size.
You can have a window that is 90% full and terrible context: four files the agent read and discarded, a long tangent about a bug you already fixed, three failed approaches, and somewhere in there the one function that matters. You can also have a window 15% full and excellent context: the two files involved, the relevant test, and a clear statement of the goal.
The signal-to-noise framing
Think of it as a ratio. Every token that is not helping is actively hurting, because of how attention works (next lesson). Adding a file "just in case" is not neutral — it dilutes.
Session A 62k tokens - full contents of 9 files, 5 of them irrelevant - two abandoned approaches, still in history - the actual task, stated once, 40 minutes ago => high volume, low context Session B 19k tokens - the 2 files being changed - the test that must pass - a 6-line statement of the goal and constraints => low volume, high context
Session B produces better code, faster, for a tenth of the cost. The difference is curation, and curation is your job — the harness will happily fill the window with whatever the agent decided to read.
Curating in practice
- Point, do not dump. Name the file and the function. A grep-and-read of a specific symbol beats reading the directory.
- Ask for a plan before the work. A plan is a cheap, high-density summary of intent that stays useful in the window. Raw exploration output is bulky and mostly stops being useful once the plan exists.
- Abandon out loud. When an approach dies, do not just pivot — that leaves the dead approach in the window, competing for attention. Start a fresh session with a one-paragraph summary of what you learned.
- Prefer narrow tool results.
grep -n "handleWebhook" -r srcis a hundred tokens. Reading the four files it might be in is twenty thousand.
Watch out
Large context windows made this problem worse, not better. When the window was small, you were forced to curate. Now the agent can read forty files without hitting a limit, and the failure is silent: no error, just steadily worse output. Treat the window as a budget you set, not a limit the tool enforces.
Try it
Take a task from your list and run it twice in fresh sessions. Once by saying "have a look around and fix X". Once by naming the two files, the relevant test, and the constraint up front. Compare the diffs, the turn count, and the token totals.
Takeaways
- Window is volume; context is relevance. Optimising the first often destroys the second.
- Irrelevant tokens are not neutral — they dilute attention on the relevant ones.
- Point at specific symbols and files instead of letting the agent explore broadly.
Your agent is at 30% of its window and producing sloppy work. What is the most likely explanation?
Poor context, not insufficient room. Something in that 30% is noise — an abandoned approach, a dumped directory listing, a long error the agent already fixed — and it is competing with the material that matters. Clearing and restating the task in six lines usually fixes it instantly.
A course by Pieter Zandbergen