1 million tokens isn't enough: how to actually manage context in Claude Code

The 1-million-token window is making a lot of noise. And rightly so: going from a 200K window to 1M changes the scale of what you can reasonably keep in an agent's head. A big repo, several spec files, a dense conversation history, test outputs, a few logs — all of that fits now without you having to MacGyver anything.

But when you actually work with Claude Code day to day, you quickly realize the question isn't "does it fit?". The question is: does what's in the context still help the model do good work?

That's exactly where everything plays out. A huge window, badly piloted, doesn't automatically deliver better results. It mostly gives you more room to pile up noise, errors, dead branches, and reasoning that has stopped being useful. The real topic in 2026 is no longer the raw size of the context. It's active management of it.

Why a 1M context is so impressive

A million tokens is a lot. On the order of several hundred pages of text, or a reasonably sized repo loaded into memory with room to spare. For Claude Code, it's a change in posture.

Concretely, Claude Code's context window holds everything the model has to be able to consult at any given time:

the system prompt and project instructions (the CLAUDE.md, tooling rules, etc.),
the full conversation history,
the tool calls the agent has performed,
the outputs of those tool calls (shell commands, searches, edits),
and the files read during the session.

As soon as you work seriously on a feature, this list grows fast. Read 10 files, run a few tests, dig through a log, refactor two modules, and you're already approaching hundreds of thousands of used tokens — without having done anything unusual.

With 1M tokens, you get headroom. You can stay in the same session longer without it choking. You can load a big context without picking by hand what to keep. For long tasks, that's real comfort.

But that comfort has a trap.

The real problem is context rot

Context rot is a simple phenomenon to explain: as the context grows, model performance eventually drops. Not because it "forgets" the window — the window is still there. But because attention spreads over more and more tokens, and because old, irrelevant or outright contradictory items start to distract it.

In practice, it looks like this:

the model picks up an abandoned lead from 40 messages earlier and revives it even though it's no longer valid,
it suggests a solution it itself rejected an hour ago,
it leans on an outdated version of a file that's been modified since,
it mixes two reasoning chains carried out in parallel on two different sub-problems,
it starts asking again questions you've already answered.

That's not a bug. It's the mechanical consequence of stacking a lot of information, much of which no longer serves the current task.

This point is fundamental: growing the window does not eliminate context rot, it just shifts when it appears. A 1M window does not guarantee constant quality. It only guarantees that you'll hit the moment when quality starts to slip later.

Hence the implicit rule behind this whole discussion: the quality of the context matters more than its size. And that is exactly what Claude Code gives you the tools to control — provided you know how to steer the session.

The 5 real ways to steer a Claude Code session

In Claude Code, every conversation turn is in fact a decision point. After each model response, you have five reasonable options. They are not equivalent, and the right discipline is to consciously choose which one to use rather than always defaulting to "next."

The five options are:

Continue — keep going as is.
/rewind — go back to an earlier message and restart from there.
/clear — wipe the context and start from a blank page.
Compact — automatically summarize the session to free up room.
Subagents — delegate a subtask to a separate agent with its own context.

Each one has a precise use case. Confusing them dooms you to either dragging useless context around or losing useful context. Let's go through them.

Practical cases, command by command

Continue: when the session is still healthy

The default. You follow up with a question, an instruction, or a correction. It's the right choice as long as the model is working well and the context is still coherent.

Good signal: Claude Code reads the right files, understands on the first pass, doesn't revisit closed leads, and its tool calls are targeted.

Bad signal: it starts re-reading irrelevant zones, suggesting solutions you already discarded, or redoing things it just did. At that point, "continue" is often a bad idea. It's better to pick one of the next options than to try to "get it back on track" through successive instructions — that's often how you degrade the context further.

/rewind: the underrated command

/rewind lets you go back to an earlier message in the conversation, removing all subsequent messages from context. It's probably the most misused tool in Claude Code, because it's culturally counterintuitive: people tend to want to "fix by moving forward" rather than "step back to relaunch."

And yet, in many cases, /rewind produces a much better result than the correction.

Typical scenario: the agent reads three files, misunderstands a part of the code, and goes off in a wrong architectural direction. You only realize after five or ten messages. Two options:

Option 1: correct in line. You explain what's wrong, you give new pieces of information, you ask it to start over. The model will try, but it keeps the entire bad lead in its context. It risks being influenced by its own prior reasoning, and you expose yourself to a perfect context rot: a session that mixes the good and bad direction.
Option 2: /rewind right after the file-reading phase. You go back to the moment when it had all the right information in mind, but before the bad decision. And you relaunch with a sharper brief: "do X, keep Y in mind, do not try to do Z."

Option 2 is almost always better. It removes the noise. It saves the agent from having to "unlearn" a wrong path. It costs you a few messages, but it saves hours of back-and-forth.

Simple rule: when you catch yourself writing "no, not like that, try something else," ask yourself whether /rewind wouldn't be cleaner.

/clear: taking control by hand

/clear is much more radical. It wipes the context and puts you in front of an almost-blank session. Nothing from the history is preserved in the window.

It costs more in human effort. You have to re-prepare a full brief, re-point at the right files, re-summarize the constraints. But in exchange, you have 100% control over what enters the new context.

That's the right choice in several situations:

you're moving on to a new, unrelated task (general rule: new task = new session),
the prior session has gotten so confused that it's faster to rewrite everything than to try to recover it,
you want to start from a fully clean brief because you yourself changed your mind about the approach,
you've done debugging that generated lots of logs, stack traces and tool calls that no longer matter once the bug is understood.

/clear is also a good reflex at the start of the day when you pick a topic back up after a break. Rather than resuming yesterday evening's session with its loaded context, a /clear followed by a clean brief is often faster.

That said, save what needs saving first. Once /clear runs, anything not written into code, a note or a doc is gone.

Compact: fast but lossy

/compact asks Claude Code to summarize the session to free up room in the window. The summary replaces a large portion of the history, which frees up a lot of tokens to keep working.

Claude Code can trigger compaction automatically as you near the window's limit. You can also trigger it manually, and it's often smarter to do so when you know where you want to go, rather than letting auto-compact fire at the worst moment.

/compact is fast. That's a real advantage: in two seconds, the session is light again. But /compact is also lossy: details are lost. Sometimes those are unimportant details, sometimes not. The model might forget a small piece of spec, a constraint you mentioned in passing, or a decision made midway.

Good use of /compact:

you stay on the same phase of the work, you just want to free up room to keep going,
you can provide a hint at compaction time, indicating what absolutely must be preserved: "compact, but keep the API constraints and the current integration plan,"
the next direction is clear in your head and in the model's.

Bad use of /compact:

you're changing topic or phase. Compacting one topic to start another is often worse than a clean /clear: you keep noise, you lose details, and you start the new phase with a tepid summary.
the model doesn't know where things are going next. In that case, the summary will be vague, generic, and a bad compact is almost guaranteed. The worst auto-compacts happen exactly in those moments, when the model can't predict the next direction of work.

Rule: /compact is a continuity tool, not a transition tool.

Subagents: send the noise elsewhere

Subagents are probably the most transformative feature for anyone who really wants to manage their context.

The idea is simple: instead of doing a noisy task in your main session, you delegate it to a separate agent, with its own fresh context. It does the work, it produces a result, and you only get the final result back in your main session — not all the intermediate tool calls, not the files read, not the trial and error.

Typical use cases:

check a spec: "read this 40-page document and just tell me which endpoints are affected by the new auth rule,"
read another codebase: "go to the neighboring repo, find how they implement X, and come back with a structured summary,"
consult external docs: "go fetch this library's docs and come back with the three points that contradict our current usage,"
run an exploratory search: "find every mention of this function in the repo, classify them by call type, ignore tests,"
any task that's going to generate a lot of intermediate noise that you really don't want to bring back into the main session.

The effect on quality is massive. Your main session stays clean, focused on the current task. The subagent does the dirty work in a corner and only brings you back the useful conclusion.

In fact, once you get into the habit of delegating to subagents, you see main sessions remain usable much longer, because they no longer grow every time a secondary check is needed.

How to choose between these options, in practice

A simple heuristic, usable after each agent response:

The model worked well and the next step is clear → Continue.
The model went the wrong way and you can identify where it derailed → /rewind to that point.
You're switching tasks or the session is too messy to save → /clear.
You're staying on the same phase but the window is filling up → /compact, ideally with a hint.
A subtask is going to generate noise you don't want to bring back → subagent.

Put differently: the bigger the context gets, the more you need to know what to keep, what to summarize, what to throw away, and when to start fresh.

What it changes for developers actually working with agents

Working with a long-context agent isn't the same activity as prompting a chatbot. It's also not "coding with a bit of help." It's a session discipline, and paradoxically it looks a lot like certain good human practices:

breaking down tasks correctly,
avoiding mixing two topics in the same window,
taking notes in the right place (in the code, in a doc, not in a chat),
knowing how to close one thread before opening another,
delegating side research instead of doing it inline.

A 1M window doesn't make those reflexes optional. It makes them more important. Because the cost of a polluted context over 800K tokens is much higher than over 50K.

That's probably the interesting insight of this generation of agents: the difference between two Claude Code users will no longer come only from the underlying model's quality. It will come from how each one structures their session around the model.

Two developers with exactly the same version of Claude Code will not get the same results if one uses /rewind, /clear, /compact and subagents at the right moments, and the other just lets the window grow until it chokes.

Conclusion

The 1M window is a real step forward. More headroom, more comfort, less duct tape. But it doesn't solve the underlying problem: a model only reasons well if what it has in front of it is relevant, coherent and up to date.

The good news is that Claude Code gives you exactly the right tools: five real options for steering a session, each with a precise role. The user's job is to consciously choose which one to activate at each decision point, rather than clicking "continue" by default.

The open question worth asking: are very large context windows really going to simplify daily work… or are they mostly going to reward those who already know how to steer their sessions? Everything suggests the second answer is right. And that's not bad news: it just means context discipline is becoming a core skill for working with agents, on the same level as reading a diff or structuring a spec.