Context and Session Management

AI-augmented work runs on two resources that are easy to treat as free: the context window and the session itself. Neither is free. The window degrades under load like any capacity-bound system, and the session accumulates damage the longer it lives.

This framework is the two resources, managed: utilization bands for the window, and deliberate abandonment for the session.

The context window is a capacity plan

The borrowed mental model: nobody runs production servers at 95% utilization on purpose - degradation near the top of the capacity curve is not linear, and the cost of hitting the ceiling mid-request is worse than the cost of headroom. The model's context window behaves the same way, and we plan it the same way, in utilization bands:

• Below 20% filled: under-provisioned. The model does not know enough about your codebase to act in its style; it will reinvent patterns you already have and make mistakes that look like incompetence but are actually missing context.
• 20–60%: the working band. Enough loaded to generate code that belongs in your codebase, enough headroom to finish the cycle.
• Above 60%: the danger zone. You may run out of room mid-review, with the diff half-discussed.
• Above 70%: the cliff. Compacting a session summarizes it, and summaries lose nuance - the constraint you mentioned forty minutes ago, the edge case you agreed to handle later. Recovering costs about ten minutes of re-feeding context, and the restored session is never quite the one you lost.

This turns task scoping into capacity planning. A task is correctly sized when the whole arc - context feed, generation, and the full review cycle - fits inside the 20-to-60 band. Generation alone fitting is not enough; the review conversation consumes window too, and running out during review is precisely the failure you planned the band to avoid.

A calibration note: these bands were worked out on 200K-token windows, and that is where the workflow runs best. Our position is that a 200K–400K window is the better tool for this kind of work than a million-token one. The small window is a forcing function - it makes you scope the task, prepare the landing zone, and keep the cycle reviewable, because you have no room to do anything else. A window large enough to hold the whole repository is an invitation to ask for the feature against everything at once. The constraint was doing real work.

One step size, two budgets

Small steps are usually sold as a quality discipline: small diffs get reviewed honestly, small commits revert cleanly. All true. But the same step size is also a context-budget discipline, and the two constraints converge on the same number. A task small enough to review thoroughly in ten minutes is a task that fits the window's working band. A task that blows the context budget is also a task too large to review with full attention. That convergence is not a coincidence - your review attention and the model's context window are both bounded resources, and the step size is how you ration both at once.

This is also why "the model can handle a bigger window now" does not change the discipline. A larger window raises the ceiling on context, not the ceiling on how much diff a human can honestly review in one sitting. The binding constraint was never only the machine.

Context rot

Utilization is the quantity problem. Rot is the quality problem, and it is sneakier. A long session does not just fill the window - it fills it with increasingly poisonous material: the three approaches you explored and rejected, the bug you chased into a dead end, the verbose explanation you scrolled past, the correction you issued and the wrong code it corrected. All of it stays. All of it is context.

Generation quality late in a long session degrades not because the model got worse but because its input did - the signal-to-noise ratio of the window decays with every detour. The window is not a whiteboard that gets erased when you move on. It is a transcript, and the transcript is the input.

The model cannot compartmentalize

Here is the mechanism underneath context rot, and it is the heart of this framework. When two humans argue for thirty minutes and land on a decision, the humans compartmentalize: the decision becomes the new baseline, and the debate gets filed away as history. Next conversation, they build on the conclusion.

The model does not do this. Its context is the totality of the transcript, and its behavior follows the totality - not the final ruling. The approach you argued against is still in the window, still shaping attention, still voting. The decision you reached does not replace the argument; it just becomes the last entry in it. Ask a follow-up question twenty minutes later and the model drifts back toward what most of the transcript said, not what was finally decided.

A claim you can test today: have a long back-and-forth with a model, win the argument, then keep working in the same session. Watch the rejected approach quietly resurface - in a variable name, an architectural suggestion, a "we could also..." The model is not being stubborn. It is being faithful to its input, and its input is mostly the debate.

Session abandonment is a tool, not a failure

The fix follows directly: sessions should end on purpose, and more often than feels natural. This collides with a deep human instinct, so name the asymmetry plainly: with humans, you never abandon a conversation - the relationship is the asset, and walking away has a cost. With a model, you must. The session is not a colleague; it is a buffer, and it only gets worse with age. Refusing to abandon it is applying conversational loyalty to a transcript.

Abandoning a session reads like losing work. It is the opposite - it is the only way to convert a hard-won decision into a clean baseline, because a fresh session reads the conclusion as ground truth instead of as the winning side of an argument it can still hear.

The triggers we treat as hard signals:

• A contested decision was just reached. The moment of agreement is the moment the session has done its job. Restate the decision cleanly, end the session, start the next one from the statement.
• You are correcting the same thing twice. The first wrong version is still in the window, still voting. A third correction in the same session is arguing with the transcript.
• The session explored more than it built. Dead ends are valuable to you and poisonous to the window. Take the conclusion, leave the archaeology.
• Utilization is at the band edge. Ending early beats compacting late - a deliberate restart carries what you choose; compaction keeps what a summary happens to keep.

The restart pattern matters as much as the trigger: carry the decision, not the debate. One clean statement of the outcome goes into the next session as opening context - and decisions worth more than one session go into the rules file (A Working AGENTS.md), where they hold without ever being argued again. What never travels: the back-and-forth, the rejected branches, the apologies. The next session deserves the conclusion at full strength, undiluted by its history.

And here is why the persistent context layer earns its keep: the real cost of abandonment is the cost of rebuilding context, and the infrastructure sets that price. A strong rules file and context models drop a restart to minutes - load them, state the decision, and the fresh session is productive immediately, standing on the foundation the change will be made on. The layer is what makes short sessions practical. Without it, restarting is expensive, so sessions stretch - and the context foundation is what shortens that restart cost. Cheap abandonment is not a habit you adopt; it is a capability you build.

The two resources, summarized

Plan the window like server capacity: work in the 20-to-60 band, size tasks so the whole arc fits, and treat the small window as the forcing function it is. Treat the session as disposable: the model cannot compartmentalize, so you do it for the model - end sessions at decisions, restart from conclusions, and bank anything durable into persistent context. The cadence that operationalizes both lives in Make the Change Easy: every cycle ends in a commit and a fresh or compacted session, which is this framework running on a twenty-minute clock.