Know When to Start a Fresh Context

A model doesn't get tired, but a conversation does. The longer a single session runs, the more it fills with detours you abandoned, approaches you tried and dropped, corrections you issued three times, and half-finished threads nobody closed. All of that stays in the window, and all of it competes for the model's attention on every new turn. At some point the accumulated residue starts costing you more than the accumulated context is worth, and the fix isn't a better prompt. It's a fresh context.

The symptoms of context rot

You don't need instrumentation to catch this. Once you've watched a few sessions go stale, the signs are unmistakable.

It re-raises a decision you already settled. Twenty messages ago you picked an approach and moved on. Now the model circles back and proposes the alternative you rejected, as if the deliberation never happened. The decision is technically still in the window, but so is all the discussion that preceded it, and the model can no longer tell the conclusion from the noise around it.
It drags in an approach you abandoned. You explored a design, hit a wall, and pivoted. Fifteen turns later the model reaches for a helper from the dead branch, or writes code that assumes the schema you threw out. The abandoned path didn't leave the context when you left it, and now it's pulling weight it shouldn't have.
It gets slower and less sharp. Responses that were tight and specific early on turn hedged and generic. The model spends more of its working memory reconciling a sprawling history and has less left for the actual question. Quality is the first thing that degrades under that load, and it degrades quietly.
It contradicts a correction you made. You told it early on "the date field is stored as a Unix epoch, not an ISO string," and it agreed and adjusted. A hundred messages later it's back to parsing ISO strings. The correction is buried under everything that came after, and buried instructions stop getting followed.

None of these are wording problems, and rephrasing your next message won't fix them. They're load problems, the same class of failure I described in scoping the task to the context window, except this time the overload built up over time inside one session instead of arriving all at once in an over-sized task.

Why it happens

The mechanism is simple and it's worth being precise about. Everything in the context window competes for attention, and the model has no built-in sense of what's current versus what's stale. To it, the message where you settled on an approach and the message where you were still arguing against it are both just tokens in the window, weighted by relevance, not by recency or by the fact that one supersedes the other.

So a long session doesn't accumulate a clean, updated picture of where things stand. It accumulates a transcript: every wrong turn, every reversal, every "actually, let's not do that" sitting right next to the decision it reversed. A human reading the transcript top to bottom understands that later statements override earlier ones. A model spreads its attention across all of it, and the garbage gets a vote. The more turns you pile on, the larger the fraction of the window that's stale, and the more that stale fraction drags the output back toward things that no longer apply.

This is why the failure gets worse rather than plateauing. It's not that any single old message is fatal. It's that the ratio of live context to dead context keeps sliding the wrong way.

The move: start fresh and re-seed

The fix is blunt: start a new context and bring forward only what still matters. Not the transcript. A tight summary of the current state.

What "current state" means is specific. It's the decisions you've actually settled, stated as decisions and not as the debate that produced them. It's the files that matter now, the two or three that the next stretch of work will touch, not the twelve you looked at along the way. And it's the goal as it stands today, which is often narrower than the goal you started the session with, because you've since carved off pieces and learned what the real remaining work is.

A good re-seed reads like a handoff note to a competent colleague who's picking up mid-project:

We're adding dedup to the email-sync parser. Decided: dedup keys on message-ID, not on subject+date. The parser is in email_sync.py; the message-ID schema is settled and lives in schema.md. Still open: how to backfill existing duplicates. Ignore the retry-logic refactor, that's a separate task.

That paragraph carries the entire live state of a session that might have run fifty messages, and it carries none of the dead branches. The model that reads it starts sharp, because everything in front of it is load-bearing. There's nothing to compete with the signal because you didn't paste in the noise.

This is the distinction from scoping a task up front. Scoping is about sizing a single unit of work before you start, so it fits cleanly with room to reason. Starting fresh is about noticing, mid-stream, that a session which may have started well has silted up, and choosing to cut a clean one rather than keep dragging the residue along. One is a decision you make at the beginning. The other is a judgment call you make while the work is in flight, and making it well is a skill in its own right. The tell is when you catch yourself correcting the model on something it already knew, or watching it relitigate a closed question. That's the moment to stop and re-seed.

Write down durable state so a fresh context is cheap

Re-seeding is only cheap if the current state is written down somewhere you can hand over. If it lives only in the conversation, then starting fresh means reconstructing it from memory, and that friction is exactly what keeps people grinding away in a stale session long past the point they should have cut it.

This is where the discipline connects back to writing things down. When you plan first and code second, the plan is durable state: it already says what the decisions are, what the sequence is, and what's done versus open. Re-seeding from a plan is nearly free, because the summary already exists as an artifact and you just point the new context at it. The same is true of a reference doc that captures how a subsystem works, or the context you'd assemble for the AI anyway. Durable written state means a fresh context can be rehydrated rather than re-derived.

This is exactly why my own setup leans so hard on written instructions. My agent definitions are markdown files with YAML frontmatter. Every project carries a CLAUDE.md that states its conventions. My reference library and gotchas files live in the repo, not in any one conversation. None of that is documentation for its own sake. It exists so that a fresh context can pick up work without re-litigating everything the last context already figured out. When I run a fleet of agents in production, no single one of them is holding a long, precious thread that would be catastrophic to lose. The durable state lives in files, and any given context is disposable by design. That's the whole point: if starting over is cheap, you'll do it at the right time instead of clinging to a session because throwing it away feels expensive.

The habit