Context is the scarcest resource in a long session. It gets spent on three things: files you read, output you generate, and narration nobody asked for. Only the first one is usually worth it.
Core Behavior
Treat the context window like a budget with a balance. Before any expensive action — reading a big file, running a chatty command, dumping a directory tree — ask what the cheapest way to get the same answer is.
Spend Rules
Read narrowly. sed -n '120,190p' file.ts beats reading a 2,000-line file to see one function. Grep for the symbol, then read the 40 lines around it. Read a whole file only when you are about to restructure it.
Search before reading. grep -rn "symbolName" --include="*.ts" costs a few hundred tokens and tells you which of forty files matters.
Silence the noisy commands. Pipe installs, builds, and test runs through a filter instead of dumping them whole:
npm test 2>&1 | tail -30
npm run build 2>&1 | grep -E "error|Error|warning" | head -20
npm install --silent 2>&1 | tail -5
git diff --stat # not git diff, unless you need the hunks
A passing test suite needs one line of proof, not 400.
Write instead of remembering. Anything that must survive — a plan, a decision, a list of files to touch — goes in a file on disk. Files are re-readable at a cost you choose; context is not.
Do not re-read what you just wrote. If an edit succeeded, it succeeded. Re-reading to "verify" is pure spend.
Cut the narration. No preamble, no recap of what was just shown, no bulleted summary of a diff the user can see. Say what changed and what is next, in a line or two.
Where the Budget Actually Goes
When a session bloats, it is almost always one of these:
| Leak | Fix |
|---|---|
| Whole-file reads for one function | grep, then a line-ranged read |
Full npm install / build logs |
| tail -n or grep for errors |
Directory listings of node_modules, dist, .next |
prune them in the find/ls |
| Re-reading files after editing | trust the edit result |
| Long explanations of finished work | one line |
| Pasting a file back to show a small change | show the diff hunk only |
| Repeating the plan every turn | plan lives in a file |
Compaction Points
When roughly two-thirds of the window is gone, stop adding and start consolidating:
- Write the current state to a plan or handoff file on disk.
- State the single next action.
- Tell the user a fresh session will be faster and more accurate than continuing.
A fresh session that reads a good plan file outperforms a stuffed session every time. Do not treat starting over as failure — it is the intended move.
Large Repos
- Map before you dig: directory names and entry points first, implementation later.
- Follow imports from the entry point rather than crawling folders alphabetically.
- One subsystem at a time. Finish it, write down what you learned, move on.
- Generated code, lockfiles, and snapshots are never worth reading. Exclude them by default.
What Not to Cut
Economy has a floor. Never skip:
- Reading the actual code before changing it.
- The error output when something failed — that is the one long dump worth having.
- The user's own requirements, quoted.
Being cheap about the wrong thing produces confident, wrong work. The goal is fewer tokens, not less evidence.