If the context window is a million tokens, do I still need to manage sessions?

Yes — arguably more than before. A bigger window lets you run longer, but model performance still drifts as the window fills (context rot), and a long session collects clutter that competes for the model's attention. The window being large doesn't make a sprawling, unfocused context a good one.

What's the difference between /compact and /clear?

/compact asks Claude to summarize the session so far and keeps working on top of that summary — easy, but lossy, since Claude decides what mattered. /clear starts a fresh session with only the brief you write down — more effort, but the new context is exactly what you chose to keep. Reach for compact when continuity matters and the thread is clean; reach for clear when you're starting something new or the session has wandered.

When should I rewind instead of just correcting Claude?

When Claude has gone down a wrong path, rewind (double-tap Esc or /rewind) to just before it went wrong and re-prompt with what you learned, rather than piling a correction on top. Correcting leaves the failed attempt in the context as noise; rewinding removes it, so Claude starts clean from the better instruction.

How is this different from context engineering?

Context engineering is the concept — what the model can see when it answers, and why a focused window beats a bloated one. Session management is the hands-on practice of it inside Claude Code: the specific moves (continue, rewind, compact, clear, subagent) you use to keep that window in good shape. One is the why; this is the how.

Session management in Claude Code: working well with a 1M context window

A common thread keeps coming up when people talk about working with Claude Code: the million-token context window is a double-edged sword. It lets Claude operate autonomously for much longer and handle bigger tasks more reliably — but it also gives clutter more room to pile up if you’re not deliberate. More headroom doesn’t manage itself.

So the questions multiply. One terminal session or two? A fresh start with every prompt? When do you reach for compact, rewind, or a subagent — and why do some compacts come out so much worse than others? There’s more depth here than it looks, and almost all of it comes down to one skill: managing your context window.

A 60-second primer: context, context rot, compaction

The context window is everything the model can see at once when it writes its next response — your system prompt, the whole conversation so far, every tool call and its output, and every file that’s been read. In Claude Code, that window holds up to a million tokens.

Using that space isn’t free. As a window fills, model quality tends to drift — attention gets spread across more tokens, and older, no-longer-relevant material starts to distract from the task at hand. This is context rot. For the 1M-token model, you start to see some of it somewhere around 300–400k tokens — but that’s a soft, task-dependent zone, not a hard line.

The hard line is the window itself. As you approach the end of it, the work-in-progress has to be condensed into a shorter description so it can carry on in a fresh window. That condensing step is compaction — it can fire automatically, or you can trigger it yourself.

Every turn is a branching point

Here’s the part most people skip past. The moment Claude finishes a turn, your context holds a pile of new material — instructions, tool calls, their outputs — and you have five real options for what comes next, not one:

Continue — send the next message in the same session.
Rewind (/rewind, or double-tap Esc) — jump back to an earlier message and try again from there; everything after that point drops out of context.
Clear (/clear) — start a brand-new session, usually with a short brief you’ve distilled from what you just learned.
Compact (/compact) — summarize the session so far and keep going on top of the summary.
Subagent — hand the next chunk of work to an agent with its own clean context, and pull back only its result.

Continuing is the natural reflex. The other four exist precisely so you can shape what’s in the window instead of letting it accrete by default. Knowing which to reach for is most of the skill.

When to start a new session

The larger window genuinely changes what’s possible — you can now have Claude build a full-stack app from scratch in a single run without bumping the ceiling. But “the window isn’t full” is not the same as “you should keep going in it.”

The rule of thumb is simple: a new task deserves a new session. Starting clean keeps the failed turns, dead ends, and irrelevant file reads of the last task from bleeding into the next one.

The grey area is related work — where some of the old context still helps but not all of it. Say you’ve just implemented a feature and now want to write its docs. You could start fresh, but then Claude has to re-read all the files it just wrote, which is slower and costs more. Since documentation isn’t an especially intelligence-sensitive task, the leftover context is probably worth keeping for the efficiency. The judgment call is roughly: how much does this next task benefit from a clean slate versus from what’s already loaded?

Rewind beats correcting

If there’s one habit that signals good context management, it’s rewind.

Double-tapping Esc (or running /rewind) lets you jump back to any earlier message and re-prompt from there — and the messages after that point are dropped from the window. That last part is the whole point.

Picture this: Claude reads five files, tries an approach, and it doesn’t work. The reflex is to type “that didn’t work, try X instead.” But that leaves the entire failed attempt sitting in the context as noise. The better move is to rewind to just after the file reads and re-prompt with what you now know:

Don't use approach A — the foo module doesn't expose that. Go straight to B.

Same information, far cleaner window. Claude takes the better path without a dead end weighing on its attention.

You can also use “summarize from here” to have Claude distil what it just learned into a handoff note before you rewind — effectively a message from the version of Claude that tried something and hit a wall, to the version about to try again.

Compact vs. clear

Once a session gets heavy, you’ve got two ways to shed weight, and they feel similar but behave very differently.

Compact asks the model to summarize the conversation and then replaces the history with that summary. It’s lossy — you’re trusting Claude to decide what mattered — but you didn’t have to write anything, and Claude is often more thorough than you’d be about pulling forward important learnings and file references. You can steer it, too:

/compact focus on the auth refactor, drop the test debugging

Clear is the deliberate version. You write down what matters — “we’re refactoring the auth middleware, the constraint is X, the files that matter are A and B, we’ve ruled out approach Y” — and start clean. It’s more work, but the resulting context is exactly what you decided was relevant, with nothing you didn’t choose.

Rough guide: compact when the thread is clean and continuity matters; clear when you’re genuinely starting fresh or the session has drifted somewhere you don’t want to carry forward.

What makes a bad compact

If you run long sessions, you’ve probably hit a compact that came out noticeably worse. The usual cause: the model couldn’t predict where your work was about to go.

The classic trap is auto-compact firing at the end of a long debugging session — it dutifully summarizes the investigation — and then your next message is “now fix that other warning we saw in bar.ts.” But the session was all about debugging, so the unrelated warning likely got dropped from the summary. The detail you needed next is exactly the detail compaction threw away.

What makes this thorny is the timing: because of context rot, the model is at its least sharp right when it’s asked to compact a nearly-full window. The fix the 1M window buys you is room to be proactive — /compact earlier, on your terms, with a note about where you’re headed (/compact keep the bar.ts warning, we're fixing that next) rather than waiting for an automatic one to guess.

Subagents: borrowing a clean window

Subagents are context management in structural form, and they shine when you know in advance that a chunk of work will spew a lot of intermediate output you’ll never need again.

When Claude spawns a subagent (via the Agent tool), that agent gets its own fresh context window. It can do all the messy work it needs — read a dozen files, run searches, take notes — and then synthesize, so only the final report comes back to the parent session. The intermediate noise never lands in your main window.

The test we use is one question: will I need this tool output again, or just the conclusion? If it’s just the conclusion, that’s a subagent.

Claude Code will reach for subagents on its own, but it’s often worth asking explicitly:

Spin up a subagent to verify the result of this work against the following spec file.

Spin off a subagent to read through this other codebase and summarize how it
implemented the auth flow — then implement it the same way here.

Spin off a subagent to write the docs for this feature based on my git changes.

The bigger picture

Step back and the pattern is clear: every time Claude ends a turn and you’re about to type, you’re at a decision point — not just what to say, but where to say it. Continue, rewind, clear, compact, or delegate. Most of your experience with Claude Code is shaped by how well you work that fork.

Over time, expect Claude to handle more of this for you. For now, it’s one of the most direct levers you have on the quality of what comes back. Try the cheapest habit first: next time an approach fails, rewind to before it went wrong instead of correcting on top — and notice how much sharper the second attempt is. If you want the concept underneath all of this, our guide on context engineering is the companion piece.