In the previous chapter on context engineering, I argued that the important work is curating the information an agent uses. Then in The Only Workflow That Works, I described separating planning from execution and keeping the specification on disk. This chapter covers the operational gap between understanding those principles and applying them throughout a long session.
You may have a one-million-token window in theory. That sounds generous, but the usable part also contains tool definitions, instructions, and conversation state. Run /context in a representative session to see what is actually free. Research on context rot also shows that retrieval quality can decline as contexts grow, even while they remain within the advertised limit.
The Economics of Context
Each Claude Code interaction carries previous conversation state. Caching and other optimisations reduce parts of the bill, but a longer session still means more material to store, retrieve, and potentially resend. The actual cost curve depends on provider caching and billing rather than following one simple formula.
Tool use compounds this. Every web search result, every file read, every MCP output lands in your context window and stays there. Mert Köseoğlu’s analysis of Context Mode puts concrete numbers on one 200K configuration: a single Playwright snapshot used 56 KB, an access log 45 KB, and 81+ active tools consumed 143K tokens before the first message. Those measurements show how quickly a particular setup can fill; they do not establish a universal cost curve for every model, provider, or cache configuration.
Why Autocompact Is Dangerous
Claude Code’s autocompact summarises older conversation state when the session approaches its usable limit. That summary is necessarily lossy and may omit a detail needed later.
This creates a familiar failure mode: a constraint present earlier in the session does not survive compaction with enough detail. A larger window delays that transition, but it does not make summarisation lossless.
Once autocompacted, reliability drops. Trail of Bits puts it bluntly in their Claude Code configuration guide: compaction is a sign the task was too large. Scope work to fit a single context window.
My preference is to save durable state to files and start a fresh session between phases rather than depend on compaction. That is more manual, but it makes the hand-off artefact reviewable.
Context Length equals Performance
One might argue that with a 1M context window, the need to compact at all, or /clear, has evaporated. Seems reasonable at first glance: load all the relevant information, do the task in one shot, there’s enough room, so why worry.
Anthropic’s announcement reports MRCR v2 benchmark scores at several context lengths. Opus 4.6 scored 91.9% at 256K and 78.3% at 1M, a decrease of 13.6 percentage points. Sonnet 4.6 went from 90.6% to 65.1%, a decrease of 25.5 points.
Those benchmark scores are not the probability that a live session will forget a particular instruction, and they do not justify interpolating a failure rate at the half-million-token mark. They do show that supporting a larger window does not imply constant retrieval quality across its full length. That is enough reason to keep context deliberate and to preserve important state outside the conversation.
The Research → Plan → Implement Split
This is the most important context management technique, and it’s deceptively simple: save your work to files before clearing.
Research fills context with tool results, file reads, web searches. By the time you have a solid plan, you might have only a fraction of context remaining. If you then ask Claude to implement in the same session, the implementation happens in a cramped, degraded context. This was painful at 200K. At 1M it’s more forgiving, but the principle hasn’t changed, especially for complex tasks that involve reading dozens of files and searching the web extensively.
Retrieval misses become more likely as irrelevant material accumulates, and research output continues to occupy the later session. Save the plan to a file, start a fresh session, load the plan, and implement from that reviewed artefact.
Store things to disk religiously. Plans, research findings, intermediate results. The benefits compound, and it isn’t just about costs: you can restart if the agent crashes, you can recover from tangents and weird agent loops, you can stop and resume work on a task from any point. The plan file is your save game. I’ve started treating this as non-negotiable, and the tooling I favour (the superpowers plugin) also uses files for each phase. The five seconds it takes to save a plan has saved me from restarting from scratch more times than I can count. And yes, “just save your work” sounds like advice from 1995. Some lessons are timeless.
Subagents: Fresh Context as a Resource
So you’ve saved your plan and cleared context. What about tasks that are inherently context-hungry, such as web research, documentation reading, or test running? You can’t avoid the work. But you can isolate it.
Each subagent gets a separate context with its prompt and the tools made available to it. It does the work and returns a result, so the main thread does not need every intermediate file read or search result. This is useful for bounded research or review tasks.
The pattern is straightforward: main agent as orchestrator, subagents as workers. Delegate context-heavy tasks (web research, documentation reading, test running) and the main conversation accumulates only the results, not the intermediate work. You can even run subagents in parallel: the main thread kicks off multiple tasks and waits. It’s not unlike having a small team of specialists, each with their own area and their own clean desk.
Practitioners who’ve embraced this pattern keep focused subagent files in ~/.claude/agents/: planner, architect, tdd-guide, code-reviewer, security-reviewer, doc-updater, and so on. Each agent is scoped with specific tool permissions, as limited tools equal a more focused execution. Personally, I prefer fewer “personas”, as I trust in the underlying capabilities of Opus/Sonnet. But this is a preference and, arguably, not a good practice.
The main constraint of this approach is that subagents can’t call other subagents. One level deep only; no matryoshka possible. But that’s enough for most workflows, and if you really need such structures you can rely on agentic teams instead. Something for a later chapter.
LSP as Context Saver
I covered LSP setup in the environment chapter, but it deserves emphasis here for its context management impact. Karan Bansal’s analysis quantifies the results.
Without LSP, “Where is this function?” may require text search and several file reads. With an LSP, the agent can request a semantic definition directly. That can save context on navigation-heavy tasks; the exact latency and number of matches depend on the repository.
Self-correcting edits amplify this. After every file edit, LSP pushes diagnostics. Claude fixes type errors and missing imports in the same turn. Without LSP, each fix is a round trip that consumes extra context as the agent locates the relevant code. With LSP, it’s one step.
For refactoring: findReferences finds every reference semantically, not just text matches. No more “grep found 47 of 52 actual usages” situations. So you get better context management, and fewer bugs due to missed usages.
If you haven’t set this up yet for your programming language, you should. It’s probably one of the highest-ROI improvements you can make to your Claude Code workflow. I’m not exaggerating.
Context Mode MCP
One of the main culprits, traditionally, when it comes to context hoarding has been MCP. Recent “just in time” loading optimisations help, but an issue remains: once an MCP is loaded, all its tools are loaded. The GitHub MCP is 5,000 tokens. Doesn’t feel like a lot, except they’re sent on every turn. And that’s just one MCP. Hence the trend to move towards Skills instead.
What if you could keep using MCP tools but dramatically reduce their context footprint? Turns out, someone built exactly that.
Mert Köseoğlu built Context Mode, an MCP server that sits between Claude Code and tool outputs, compressing results. The approach works by spawning an isolated subprocess for each execute call. Scripts run code, capture stdout, and only stdout enters the conversation. Raw data never leaves the sandbox.
Cloudflare’s Code Mode is a similar kind of utility, which compresses tool definitions by replacing entire tool catalogues with a search() and execute() pattern, reducing definition overhead from tens of thousands of tokens to roughly 1,000 regardless of API surface.
As mentioned, the majority opinion seems to be that Skills are preferable to MCPs, but I’ve also read well-argued counterarguments about why we should still use MCPs. Including (but not limited to) the fact that MCPs are called more reliably than Skills, at least for now. So these tools may be of interest, to slow down the rate at which you approach a context window size that forgets the data you care about.
The Practical Reality
So what does all this add up to in daily practice? A handful of habits.
Prefer a fresh session between major phases, but save and review the plan first. /compact remains useful when continuity matters more than a clean boundary; do not assume its summary preserves every constraint. Keep critical state in files either way.
Be deliberate about which MCPs you load per task: don’t load Playwright when you’re doing backend work, don’t load database MCPs when you’re working on the frontend. Use /mcp to manage configured servers. Eric Holmes makes a compelling case that for many tasks, CLIs are the better choice: cheaper, debuggable, and composable via pipes. Prefer CLI where possible. The output is typically more concise, and you control what’s returned. Tools like RTK improve on that CLI output.
Kill contaminated context aggressively: one mission, one session. If things go sideways, press Esc twice to rollback to a previous prompt, or /clear and start fresh.
Beware what you install. Run /context after adding any new skill, MCP, or configuration. I’ve seen popular tool collections consume over 50% of a 200K context window before you’ve typed your first prompt. In the new 1M environment, that’s still 10% gone. That’s not an environment; that’s a trap.
The Bigger Picture
The context window is a finite resource, even at one million tokens. Every technique in this chapter exists because irrelevant material can make useful information harder to retrieve. The analogy to human attention is imperfect, but the operational lesson is similar: a larger workspace full of noise is still noisy.
The developers I see getting the best results aren’t the ones with the fanciest setups. They’re the ones who treat context like a finite budget, who clear aggressively, who save to disk compulsively, who ask “does the agent actually need this information right now?” before providing it.