Context Management in Claude Code

Claude Code has a 1M context window now. That changes a lot. It does not change the core rule: a bigger window does not fix bad session management.

What actually shapes results is the decision you make after each turn:

• keep going in the same session
• /rewind to a better branch
• /clear and start clean
• /compact and keep the summary
• move the next chunk into a subagent

That is the real context-management layer in Claude Code. Most bad sessions are not caused by the model being weak. They are caused by carrying the wrong context forward for too long.

The official Anthropic guidance on April 15, 2026 sharpened this point: every turn is a branching point. This page turns that into a practical operating system.

Quick Win

Use these two rules immediately:

1. New task, new session. If the work changed meaningfully, run /clear or start a fresh claude session.
2. Wrong path, rewind instead of correcting. If Claude went down the wrong branch, use /rewind instead of stacking "that didn't work, try this instead" on top of stale context.

If you only adopt those two habits, your average session quality goes up fast.

Context, Compaction, and Context Rot

The context window is everything the model can see for its next response:

• system prompt
• your conversation history
• tool calls and outputs
• files read into context
• loaded memory and instructions

Claude Code can hold much more than it used to. That does not make context free.

As context grows, performance can degrade. Anthropic calls this context rot: attention gets spread across more tokens, stale material sticks around, and older irrelevant details start competing with the task you actually care about now.

When the window gets too full, Claude Code compacts the session. That means the current conversation is summarized into a smaller description and the work continues on top of the summary. Useful, but lossy.

The key mistake is treating context like an archive. It is not an archive. It is active working memory.

Every Turn Is a Branching Point

Once Claude finishes a turn, you have several valid moves. The right one depends on whether the current context is still load-bearing.

If you remember one table from this page, use that one.

Five Everyday Scenarios

This is where the abstractions become usable. Most real sessions fit one of these patterns.

1. Feature implementation turns into docs

You just finished the auth middleware and now want migration notes and docs for that same change.

Best move: continue in the same session

Why: the code, decisions, and edge cases are still useful. Rebuilding that state would just cost time.

2. Claude picked the wrong implementation path

It read the right files, but then committed to an approach that does not fit the codebase.

Best move: /rewind

Why: keep the useful exploration, drop the failed branch.

3. One task, too much debugging residue

You are still on the same feature, but the session is full of false starts and dead-end logs.

Best move: /compact with a hint

Why: the task is still the same; the session just needs pruning.

4. You are switching from coding to roadmap planning

Related domain, different task shape.

Best move: /clear or start a fresh session

Why: the implementation residue is now mostly noise.

5. You need a broad audit, but only the conclusion matters

You want a side investigation into another repo, a spec check, or a wide search.

Best move: subagent

Why: keep the intermediate noise out of the parent thread.

When to Stay in the Same Session

Keep going in the same session when:

• it is still the same task
• the files Claude just read are still directly relevant
• the current reasoning chain is still useful
• rereading everything would be slower and more expensive than continuing

Classic example: you just implemented a feature and now want Claude to write the docs for that exact feature. Starting fresh would work, but Claude would have to reread the code it already has in context. If the task is adjacent and the current session is still clean enough, continuing is reasonable.

The question is not "is this related?" The question is "is this current context still helping?"

When to Start a New Session

Anthropic's rule of thumb is simple: when you start a new task, you should also start a new session.

Start fresh when:

• you moved from one feature to another
• the session contains a lot of debugging or exploration noise
• the previous branch of work is finished
• the next task needs different files, different goals, or different constraints

This matters even with 1M context. The bigger window gives you more room before compaction. It does not make irrelevant context harmless.

Good examples of a fresh-session move:

• finished the auth refactor, now starting billing
• finished implementation, now doing roadmap planning
• spent 40 minutes debugging one failure, now switching to a different issue

If you need continuity, write a short handoff into the first prompt of the new session:

We just finished the auth middleware refactor.
What matters for this new task:
- the session format stayed unchanged
- files that matter now are X and Y
- we ruled out approach Z
New task: write the migration notes and docs.

That is often cleaner than dragging the entire old session forward.

Rewind Instead of Correcting

/rewind is one of the highest-leverage session-management tools in Claude Code and one of the least used well.

When Claude reads a bunch of files, chooses the wrong approach, and you respond with:

That didn't work. Try B instead.

you are keeping the failed attempt, its reasoning, and your correction all inside the same context. Sometimes that is fine. Often it is just contamination.

Better pattern:

1. rewind to the point just after the useful exploration
2. keep the valuable file reads
3. drop the failed branch
4. re-prompt from there with what you learned

Example:

Don't use approach A. The foo module does not expose that.
Go straight to approach B using the existing adapter in src/lib/foo.ts.

This gives Claude the useful context without the bad branch piled on top.

Rewind is best when:

• exploration was useful
• the attempted implementation was wrong
• you learned something specific
• you want to keep the evidence but not the failure path

/compact vs /clear

These are not interchangeable.

Use /compact when:

• it is still the same task
• the session is bloated
• you want Claude to preserve the important learnings
• the work is continuing in the same direction

You can steer compaction:

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

That is especially useful now that 1M context gives you more time to compact proactively, before the model reaches its worst context state.

Use /clear when:

• it is a new task
• you do not trust the current context anymore
• you want full control over what survives
• you would rather write the handoff yourself than trust a lossy summary

The difference is simple:

• /compact asks Claude to decide what mattered
• /clear lets you decide what mattered

What Causes a Bad Compact

Anthropic's explanation is useful here: bad compacts often happen when the model cannot predict the direction your work is going next.

Example:

1. you spend a long session debugging one issue
2. autocompact fires
3. the summary focuses on that debugging path
4. your next prompt switches to a different but related issue
5. the detail you wanted was dropped because the compact did not think it would matter

This is why manual /compact beats passive autocompact in a lot of real work. You can tell Claude what the next direction is before it summarizes.

A useful rule:

• if you know the next phase, compact before Claude has to guess it

Bad:

• debug for 45 minutes
• let autocompact fire
• then suddenly pivot

Better:

• finish the debugging phase
• run /compact focus on the fix plan and the files that matter next
• continue into implementation

The Anti-Patterns To Avoid

Bad context management is usually not dramatic. It is just a series of small lazy decisions.

Watch for these:

• Using one marathon session for unrelated work
• Correcting a bad branch instead of rewinding it
• Waiting for autocompact when you already know the next phase
• Letting noisy research happen in the parent session
• Treating "related" as good enough reason to keep going

These are the habits that make a strong model look inconsistent.

Use Subagents to Keep Intermediate Noise Out

Subagents are not just a delegation tool. They are a context-management tool.

The Anthropic mental test is strong:

Will I need this intermediate output again, or just the conclusion?

If the answer is "just the conclusion," a subagent is often the cleaner move.

Good subagent candidates:

• read another codebase and summarize a pattern
• verify an implementation against a spec
• write docs from your git diff
• perform a broad search you do not want cluttering the main thread
• run a focused audit and report back

Why this works:

• the child gets a fresh context window
• it can generate a lot of intermediate tool output
• only the final synthesis comes back to the parent

This is one of the easiest ways to keep a main session useful for longer.

The Practical Session Rules

If you want a compact playbook, use this:

Rule 1: New task, new session

Related is not the same as same.

Rule 2: Wrong branch, rewind

Do not stack corrections on top of a failed path if the failed path itself is now noise.

Rule 3: Same task, bloated context, compact with a hint

Do not wait for autocompact if you already know what should survive.

Rule 4: If the next step is noisy, use a subagent

Keep the parent context for decisions, not exhaust.

Rule 5: Bigger context means fewer forced resets, not no resets

1M context is a real upgrade. It is not immunity.

What 1M Context Actually Changed

The 1M window changed the economics of session management in three ways:

1. fewer forced compactions
2. more room for longer coherent tasks
3. more time to compact proactively before things get sloppy

It did not change the need to:

• start fresh on new tasks
• rewind bad branches
• avoid dragging stale debugging through unrelated work
• push noisy work into subagents

The biggest misconception after 1M context shipped was "I can keep everything in one session now." Technically, longer sessions are possible. Operationally, you still want cleaner boundaries than that.

/usage and What to Watch

Anthropic says the new /usage command was informed by customer conversations around long-running sessions and the new 1M window. That fits the real problem: most users do not just need more context, they need better visibility into how they are using it.

For day-to-day decisions, watch three things:

• whether the current task is still the same task
• whether the current context is still helping
• whether the next step needs detailed intermediate output or only the conclusion

That is more actionable than obsessing over raw token counts alone.

A Better Context Habit Loop

Use this sequence through a real workday:

1. start a session with one clear task
2. continue while the current context is still useful
3. rewind when a branch goes bad
4. compact at natural phase changes, with a hint
5. clear when the task changes
6. spawn subagents for noisy side work

That is the operating model.

A 30-Second Decision Test

When you are unsure what to do next, ask three questions:

1. Is this still the same task?
2. Is the current context still helping more than hurting?
3. Will I need the next step's intermediate output later?

If the answers are:

• yes / yes / yes -> continue
• yes / no / yes -> compact
• yes / yes / no -> subagent
• no / no / maybe -> clear and restart

That is usually enough to make the right call without overthinking it.

Sources

• Using Claude Code: session management and 1M context
• Subagents - Claude Docs

Related Pages

• 1M Context Window in Claude Code
• Context Buffer Management
• Context Engineering
• Dynamic Starting Context