Claude Code now ships with a one-million-token context window. That number is misleading in exactly the way large numbers usually are: it suggests the constraint moved from "running out of room" to "never running out of room." It didn't. Anthropic calls what actually limits you context rot. The observation that model performance degrades as the window fills, because attention spreads across more tokens and older, irrelevant content starts competing with what you're doing now.
I've run between three and twelve concurrent Claude Code sessions daily for over a year. The sessions that produce garbage rarely die because they hit the hard cutoff. They die because the window is full of low-signal noise. Repeated file reads, stale debugging loops, tool output nobody asked for. And the model is at its least reliable precisely when auto-compaction fires to save the session.
This article is about preventing rot before it happens, not recovering from it after.
The 1M token trap
A bigger window is genuinely useful. You can trace a behavior across twenty files in one pass, review a large diff without chunking, or keep an architectural decision in working memory while implementing across a module. But volume is not the same as relevance. A focused forty-thousand-token session often outperforms a cluttered one-hundred-eighty-thousand-token session on the same task.
The trap is treating headroom as permission to accumulate. Every token in the window costs you twice: once in API spend, once in attention quality. The /context command in recent Claude Code builds breaks the window into named categories. System prompt, MCP tools, memory files, messages, autocompact buffer. And shows you how close you are to the auto-compaction threshold. That percentage is the number worth watching, not the absolute token count.
Auto-compaction summarizes earlier conversation when you're nearly out of room. The summary is written by the worst version of the session. Long past the point where recall is reliable. If you're going to compact, do it proactively at a natural task boundary while you still have headroom, with explicit instructions about what must survive. Waiting for single-digit percent until auto-compact means you already missed both better options.
Signal vs noise
Context rot isn't caused by long sessions. It's caused by low signal-to-noise ratio in the window. A session that is eighty percent load-bearing architectural context can stay sharp for hours. A session that is sixty percent failed grep output, three variations of the same wrong fix, and exploratory reads of files that turned out to be irrelevant will rot in forty minutes.
The noise sources I see most often in fleet operation: redundant tool output, where an agent reads the same config file four times because it forgot it already had the contents in context. Unresolved debugging loops, three attempts at the same fix, each with full stack traces, none marked as abandoned. Exploration that never got summarized, twenty minutes of file-spelunking left in the transcript instead of a three-sentence conclusion. And stale assumptions carried forward, a wrong hypothesis from early in the session that the model keeps reverting to because it's still in the history.
The fix for each is the same class of move: get the conclusion into a durable file or a fresh context, and get the raw exploration out of the main window.
Three defenses that actually work
1. Files over history. Anything that should survive the session belongs on disk, not in the transcript. CLAUDE.md for conventions and pitfalls the agent can't derive from the repo. AGENTS.md for role-specific operating rules. Sprint specs with acceptance criteria. A handoff file updated at session end. Files loaded at session start don't grow during the session and don't contribute to rot. They're also editable. You can delete a line that has gone wrong, which you cannot do cleanly with a compaction summary.
This is the same principle behind fractal context and context-vault: stable knowledge lives outside the ephemeral window.
2. Subagents for exploration. When an agent needs to grep across a large codebase, read logs, or investigate a hypothesis, that work belongs in a subagent with its own fresh context window. The subagent returns a synthesized result; the raw reads never enter the parent session. Anthropic's own guidance matches what I've found in production: delegate file-spelunking and verbose research, keep the main window for decisions and implementation.
3. Clear at task boundaries, compact only when you must continue. When a task is done and the next task is unrelated, /clear and start with a fresh brief. Don't compact stale work forward. A summary still costs tokens and often carries the wrong assumptions. Use /compact only when you're mid-task, the context is still relevant, but the window is filling with tool output you no longer need. Compact with instructions: /compact focus on the auth refactor decisions and the three files we changed.
For the full restart-vs-continue decision tree, see When to restart a long-running Claude Code session.
Fleet-scale: who owns the rot budget
Running multiple sessions changes the calculus. In my setup, manager sessions stay lean. They dispatch work, read status files, and make routing decisions. They don't implement. Worker sessions do the implementation and are allowed to rot. Because they're disposable. When a worker's output quality drops, I kill the session and respawn with the spec on disk, not with a compaction summary of its confusion.
That separation is load-bearing. A manager that has absorbed three workers' worth of debugging output is worse than useless. It makes bad dispatch decisions with high confidence. Keeping managers under fifty thousand tokens of conversation history is a deliberate policy, not austerity.
The filesystem is the shared memory layer between sessions. Sprint folders, git state, and spec files mean a killed worker doesn't lose progress. Only the noisy transcript dies.
When compaction is the wrong move
Compaction is a lossy compression of something you already failed to curate. It's the right tool when you genuinely must continue the same task past the window limit and you've been discarding noise as you go. It's the wrong tool when the model keeps reverting to a wrong assumption: the assumption is in the history, and a summary will carry it forward, so clear and rewrite the brief by hand instead. It's also wrong when you're at single-digit percent until auto-compact. You missed the proactive window; clear, load the spec from disk, and restart. And it's wrong when the "same task" is actually three tasks wearing one label. Split them, and clear between each.
Context rot is not a bug in Claude Code. It's a structural property of how attention works in large language models. The one-million-token window didn't remove the constraint. It moved it from "you ran out of room" to "you filled the room with the wrong things." Curating what enters the window, and what stays on disk instead, is the operational skill that separates sessions that compound from sessions that decay.