The longer you work with a coding agent, the more its memory, not its intelligence, decides whether the session stays sharp or quietly falls apart. A model that reasons brilliantly at hour one can lose the thread by hour four — not because it got dumber, but because the context window filled with clutter and the important decisions scrolled out of reach. Treating that window as a budget you spend deliberately, rather than a buffer that fills by accident, is the single biggest lever most people never pull.
Table of Contents
The window is a budget, not a buffer
Every message, file read, and tool result an agent produces lives in a fixed context window. When it fills, the session summarizes older turns into a lossy recap and keeps going. That recap is a genuine trade: exact details — a code snippet, an error string, a file path — are replaced with a paraphrase. Useful, but not the same thing.
Because the summary is lossy, when it happens matters as much as that it happens. Let it fire automatically at the last moment and you get an uncontrolled summary at the worst time — mid-edit, with no headroom left to finish the current step. Trigger it yourself, at a natural boundary, and you decide what survives.
Compaction is a trade, not a free save. Spend it on purpose.
Compact at a boundary, around three-quarters full
The habit that pays off: watch the context meter, and when it crosses roughly 70–80% and you’re between logical steps, compact deliberately — ideally with a one-line hint about what to preserve (“focus on the build we just finished and the remaining tasks”). A task boundary is the cheapest place to do it, because less live working state is in flight.
Two mistakes bracket that sweet spot:
- Too early (say 30%) wastes fidelity for space you don’t need, and often makes the agent re-read files it still had. There’s also little to compress well when there isn’t a clear chapter to fold up.
- Too late (waiting for the automatic pass) hands control to the machine at the moment you can least afford it.
Compact between chapters, not mid-sentence.
Compact at a boundary ~70-80% full not the auto-pass
One checkout per session reap it once merged
Query the live remote not a stale local copy
Store the whole response select fields downstream
Context, working state, other people's servers: each is finite, and each stays cheap only when you spend it on purpose.
Give every parallel task its own workspace
The subtler failure isn’t about the window at all — it’s about shared state. Run two agent sessions against the same checkout of a project and they share one working directory and one staging area. A broad “stage everything and commit” in one session will happily sweep up the other session’s half-finished work into the wrong changeset. Nobody notices until a review turns up files that don’t belong — the same class of collision as a human and an automation driving one browser tab, where two actors on one mutable surface corrupt each other’s work.
The fix is boring and total: one workspace per session. Give each task its own isolated checkout — a git worktree, one per parallel agent — so two sessions can never step on one another. It costs a few seconds of setup and removes an entire category of “where did that change come from?” incidents.
And reap as you go. Isolated workspaces are cheap to create and easy to forget; on a busy stretch it’s normal to accumulate a dozen, most already merged and doing nothing but adding confusion. Clearing the merged, clean ones is part of the loop, not a chore you do “later” — later never comes.
Read the source of truth, not the stale copy
A specific trap worth naming: a shared, long-lived checkout of a project’s main branch drifts behind the real remote the moment anyone merges. Search that local copy and you’re reading yesterday’s tree — you’ll “confirm” something is a certain way when it changed hours ago. When the question is “what’s actually on main right now?”, ask the remote reference directly instead of the local working copy. It’s a one-line change of habit that prevents confidently-wrong answers — the same distinction as a real loss versus a merely stale read, where trusting an out-of-date view invents a problem that the system of record would have denied.
Capture raw, interpret later
The last principle comes from data collection, but it’s really about the same budget in a different currency. When an agent gathers information from an outside source — pages, feeds, API responses — the temptation is to keep “just the fields we need” at collection time. That’s a quiet bet that today’s questions are the only questions you’ll ever ask.
That bet loses silently. The day a new question arrives, the answer is in a field you dropped, and the only way back is to collect it all over again — slower, and harder on whoever’s server you’re pulling from. Store the whole thing; select downstream, where the choice re-runs for free. A size or checksum check won’t save you here: it happily passes on a trimmed copy, because it’s comparing the copy against itself.
Trimming at capture is interpretation in the wrong layer — and it’s unrecoverable without doing the work twice.
The short version
None of these is exotic. Compact on purpose, at a boundary. One workspace per task, reaped when done. Read the live source, not a stale local copy. Capture raw and interpret later. Every one of them treats a finite resource — context, working state, other people’s servers — as something you spend deliberately instead of consume by default. Do that consistently and long agent sessions stop degrading into guesswork and stay as sharp at the end as they were at the start.
Frequently Asked Questions
How do I keep a coding agent sharp over a long session?
Treat its context window as a budget. Compact on purpose at a task boundary, give each parallel task its own workspace, read the live source of truth rather than a stale local copy, and store raw captures so you can re-select later. The through-line is that each habit spends a finite resource deliberately instead of letting it fill, collide, or go stale by accident.
When exactly should I compact?
Around 70–80% of the context window, at a task boundary, with a one-line hint about what to keep. Don’t wait for the automatic pass, and don’t do it every few minutes — a typical long session compacts a handful of times, at chapter breaks.
Isn’t compacting early “safer”?
No. Early compaction discards exact detail for space you don’t need and often forces the agent to re-read what it just had. It’s most useful only when you’re pivoting to genuinely unrelated work — and even then, a fresh session is often cleaner.
Why one workspace per session instead of just being careful?
Because “be careful” fails under load. Two sessions sharing one checkout share one staging area, so a single broad commit can capture the wrong work. Isolation makes the mistake impossible rather than merely unlikely.
How do I know the local copy is stale?
Assume it is, the moment anyone else could have merged. A long-lived local checkout only matches the remote until the next merge lands, and nothing warns you when that happens. Rather than trusting a search of the working tree, ask the remote reference directly whenever the answer must reflect “what’s on main right now.”
Why keep raw captures instead of just what I need?
Because you can’t know today which field tomorrow’s question needs, and re-collecting is costly and rude to the source. Selecting downstream is free and repeatable; trimming upstream is a one-way door.
