Claude Code: When to Compact Context vs Start a New Session

If you are still on the same Claude Code task and the window is full of stale debugging, run /compact with a short hint about what must survive. If the next prompt would make sense to a teammate who never read the transcript, start a new session with /clear and a written brief. Do not wait for auto-compact to fire at the edge of the window. That is when the model is least able to decide what mattered.

Those two moves look similar because both free tokens. They are not interchangeable. Compaction is a lossy summary of the same conversation. A new session is an empty conversation that still reloads project files from disk. Mixing them up is how people lose a constraint they never wrote down, then watch the assistant wander.

What actually fills a Claude Code session

A Claude Code session is not just your latest prompt. The context window holds the system prompt, CLAUDE.md, auto memory, skill descriptions, MCP tool names, every file Claude has read, command output, and the full back-and-forth. Each later turn re-sends that pile. The window is a hard cutoff. Quality also drops before the cutoff, because attention is spread across more tokens and older, irrelevant material starts competing with the current job. Anthropic calls that context compression pressure, and it is why a million-token window is not a license to keep one chat forever.

I would run /context before I compact or clear. The status bar percentage tells you that the window is filling. /context tells you what is filling it. A noisy test log is a different problem from a huge file read, and the fix is different.

Claude Code also auto-compacts as you approach the limit. That pass uses the same summarizer as manual /compact. Other tools handle this differently. Open WebUI, for example, can skip the step entirely until you enable it and match a compaction trigger checks against the backend window. In Claude Code the safety net is on. The question is whether you want Claude to summarize at the worst moment, or you want to choose the moment.

What manual compaction actually does

/compact keeps you in the same session. Claude Code sends the conversation to the model with a summarization prompt, then replaces the history with that summary. You can steer it:

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

That hint is the difference between a usable recap and a vague one. Without it, Claude decides what mattered. On a clean, linear task, that is often fine. On a branchy debugging session, it drops the one fact you still need.

Compaction is lossy on purpose. Full tool outputs and intermediate reasoning go away. Official docs say the summary is meant to keep your requests, key technical concepts, files examined or modified with important snippets, errors and how they were fixed, pending tasks, and current work. That is the design. It is not a guarantee that a specific constraint from twenty turns ago will be quoted back to you.

What comes back after /compact

Not everything lives in the message history. After compaction, Claude Code reloads several things from disk and from the current repo:

The system prompt and output style still apply.
Project-root CLAUDE.md and unscoped rules are re-injected from disk.
Auto memory is re-injected from disk.
Git status is read fresh.
A plan written in plan mode is re-injected from disk.
Invoked skill bodies are re-injected, capped at 5,000 tokens per skill and 25,000 tokens total, oldest dropped first.
Background commands and background subagents keep running.

Files are only partially restored. Right after compaction, Claude Code re-reads up to five of the files it already read or edited, most recently modified first. A file over 5,000 tokens comes back as a path reference without its contents. Path-scoped rules and nested CLAUDE.md files in subdirectories do not sit in the startup payload. They load when Claude reads a matching file again, so compaction summarizes them away until that happens.

The pattern is simple: if it was loaded from disk at startup, it comes back. If it arrived through the conversation, it gets folded into the summary. Anything you cannot afford to lose should already live in project-root CLAUDE.md, auto memory, or a file you will point at in the next prompt.

What a new session throws away

Starting a new Claude Code session means an empty conversation window. The usual command is /clear. Aliases include /reset and /new. Your project-root CLAUDE.md, unscoped rules, and auto memory still load. The chat history does not. There is no summary of the failed approach, the file you already ruled out, or the error you spent forty minutes chasing.

The previous conversation is not deleted from disk. Interactive sessions are saved as you work. You can come back with /resume, claude --resume, or claude --continue for the most recent session in that directory. /clear still cannot be undone inside the live chat. If I might need a snippet from the current window, I would copy it out or compact first.

Exiting and running claude again is the same decision with a slightly different shell: a fresh process, a fresh window, the same project files. Use whichever is faster. The important part is that you, not the summarizer, decide what crosses the boundary.

How I would choose

Anthropic’s own rule of thumb is the right default: /compact when you are continuing a long task, /clear when you start a new one. I would apply it this way.

Situation	Reach for	Why
Same task, and the window still holds load-bearing files and decisions	Keep going	Rebuilding that context costs time and tokens
Same task, but the window is bloated with stale logs, dead ends, or exploration	`/compact` with a hint	You need room without rewriting the brief
Claude took a wrong path, and the useful file reads happened before that	`/rewind` (Esc Esc)	Drop the failure, keep the reads, re-prompt with what you learned
The next prompt is a genuinely different job	`/clear` plus a short brief	Zero leftover rot, and you control what carries forward
The next step will dump a lot of output you only need a conclusion from	A subagent	The noise stays in the child window; only the result comes back

The test I use is blunt. If the next prompt would make perfect sense in a brand-new terminal, I would clear before sending it. If I would have to paste a recap of the last hour for the work to continue, I would compact, or I would write that recap myself and then clear.

A 1 million token window on models that support it (including Fable models, Sonnet 5 and later, Opus 4.6 and later, and Sonnet 4.6) delays this choice. It does not remove it. Context rot still shows up. You have more time to compact on your terms, with a description of what comes next, instead of letting auto-compact fire when the window is already noisy.

How to compact without losing the plot

Manual compaction is only as good as the hint and the moment. I would compact:

After a major piece of the current task is done, before the next piece starts.
When /context shows the window filling with tool output you no longer need verbatim.
Before a break of more than a few minutes, while the prompt cache is still warm.

The cache point matters for cost. Writing the summary is much cheaper while the old conversation is still cached. On a subscription, that cache expires after about an hour. On an API key it expires in about five minutes unless you enable the longer cache. Compact before you walk away, not after you come back to a cold session.

Steer the summary toward the future, not the past:

/compact keep the migration plan, the failing test names, and the files already edited; drop the search traces

If you always want the same things kept, put a “Compact instructions” section in project-root CLAUDE.md. That file is re-injected after every compact, so the instruction survives the thing it is trying to control.

I would not compact as a way to undo a bad stretch. Compaction keeps a compressed version of the failure in the window. /rewind is the cleaner cut: jump back to just after the useful file reads, drop the failed attempt, and re-prompt with the lesson. “Try again” leaves the bad attempt in context. Esc Esc erases it.

You can also compact only part of the conversation. Run /rewind, pick a message, and choose summarize from here or summarize up to here. That is useful when the early exploration is junk and the last few decisions are not.

If you are on a 1M model and want auto-compact to fire earlier than the default, /autocompact 200k (Claude Code v2.1.221 or later) puts a closer safety net back. That is a threshold choice, not a reason to skip hints.

How to start a new session without starting from zero

A new session is cheap and clean. It is also amnesiac about the conversation. The quality of the next hour depends on the brief you write, not on hope that Claude “still knows.”

I would /rename the current session before /clear if I might resume it. Then I would paste a short handoff as the first message of the new chat. Keep it specific:

Continue the checkout API refactor.

Constraint: do not change the public URL shape.
Files that matter: src/checkout/session.ts, src/checkout/session.test.ts.
Already done: extracted the session factory; tests pass.
Ruled out: storing the cart in cookies; we hit the size limit.
Next: move tax calculation behind the existing pricing helper, then run the checkout test file.

That is more work than /compact. It is also how you avoid a summary that quietly dropped the constraint. The model is at its least precise when it auto-compacts a bloated window, because that is when context rot is worst. A brief you wrote while you still remember the task beats a summary written at the wall.

If the assistant has been ignoring standing rules after a long chat, do not treat a new session as the first fix. Check that the instruction actually lives on disk and loads. Conversation-only rules vanish on /clear and get summarized on /compact. Persistent guidance belongs in CLAUDE.md, which is the same reason people see forgotten project instructions after a reset: the file was missing, too vague, or fighting another rule, not because the new window is broken.

When neither command is the real problem

Two other tools sit beside compact and clear.

Rewind is for a wrong path inside a still-valid task. Keep the file reads. Drop the failed edit. Re-prompt with what you learned. If the last few turns are the only problem, this is better than summarizing the whole mess.

Subagents are for a step that will generate a lot of intermediate output you do not want in the parent window: a repo-wide search, a verification pass, a first draft of docs. The child gets a fresh window. You get the conclusion. That is often a better way to “start fresh” for one step than clearing the parent session.

Bloated context also makes scope errors more likely. Once the window is full of unrelated files and dead ends, an assistant is more willing to “tidy” something you did not ask for. If that is already happening, tightening write boundaries matters as much as freeing tokens. The same session that needs a compact may also need a narrower prompt so you stop seeing unrelated file edits.

Cost is a reason to split work, not just quality

Usage limits and the context window are different. The window is how much the model can consider at once. Usage is how many tokens you have already spent. Filling the window hurts quality. Re-sending a huge window every turn hurts the bill and the quota.

One long session costs more than the same work in a few short ones, because turn 40 also re-reads the 39 turns before it. Cached input is cheaper than uncached input, but it still adds up. Switching models or effort mid-session is also expensive, because it can bust the cache. The cheap moments to change model or effort are the start of a session and right after a /clear.

So I would not keep a session alive just because there is still room in a 1M window. If the next job is unrelated, clear it. You get better answers and you stop paying to re-read yesterday’s stack trace.

Put anything durable on disk

The decision between compact and a new session gets easier when the session is not your only memory.

Project-root CLAUDE.md is the standing contract. Keep it lean. It reloads in full after every compact and into every new session, so bloat here taxes every turn. Path-scoped rules and nested CLAUDE.md files are the right place for directory-specific guidance, with the trade-off that they are absent right after compaction until Claude reads a matching file again. If a rule must survive every compact, drop the paths: frontmatter or move it to the project root.

Auto memory is for learned facts that should outlive a chat. A plan file in the repo is for the current piece of work. A handoff message is for the next session. Conversation history is for the current task only.

If a single file or tool output is so large that the window refills immediately after each summary, Claude Code stops auto-compacting after a few attempts and shows an error instead of looping. That is not a prompt problem. Split the work, push the heavy read into a subagent, or stop feeding the whole file through the parent window.

A workflow I would actually follow

Start a session for one job, not for “the afternoon.”
Run /context once early so you know what loaded from disk.
Use rewind when a short stretch went wrong.
Use a subagent when the next step is a noisy search or check.
When the same task is still live but the window is dirty, /compact with a hint aimed at the next step.
When the job changes, write a five-line brief, /rename if you want the old chat back, then /clear.
Compact before a long break so the summary runs while the cache is still hot.

If you only remember one line: compact to continue, clear to change jobs, rewind to undo a wrong turn.

FAQ

Does /compact keep my CLAUDE.md rules?

Project-root CLAUDE.md and unscoped rules are re-injected from disk after compaction. Rules that only exist in the chat are summarized and may vanish. Nested CLAUDE.md files and path-scoped rules come back only after Claude reads a matching file again.

Is /clear the same as closing Claude Code?

For the conversation, yes: you get an empty window and project files reload. The old session remains on disk, so you can resume it later. Closing the process also starts clean the next time you launch claude in that directory. Use /clear when you want to stay in the same terminal. Use a new process when you want a separate shell.

Should I turn off auto-compact and only compact by hand?

Only if you will watch /context and compact before the window is full. Auto-compact is the safety net. Manual compact with a hint is the better version of that net. Disabling it without a habit just means you hit the wall instead.

Why did quality drop even though I still have room in a 1M window?

Room is not the same as relevance. A window full of failed attempts, unrelated files, and raw command output still spreads attention. Compact with a hint, rewind the bad stretch, or start a new session with a brief. Do not treat unused tokens as proof that the context is healthy.

Can I recover a session after /clear?

You cannot undo /clear in place. You can resume the saved transcript with /resume or claude --resume if you still have the session. Rename first if you expect to hunt for it later.

When is a subagent better than compacting?

When the next step will generate a lot of output you only need a conclusion from. Compaction compresses the parent window. A subagent never puts the noise in the parent window. For a repo search, a test run, or a first-pass review, I would isolate that work rather than summarizing it after the fact.

On your next long task, check /context before you hit the wall. If you are still building the same thing, compact with a hint. If you are about to start something else, write the brief and clear the session. The command is cheap. Re-teaching a constraint you never saved is not.