Why /compact and /clear Exist: Managing the Context Window
A Claude Code session's context window is not infinite.
Every prompt, file read, tool output, and response adds up, and a long enough conversation eventually fills that space.
/compact and /clear exist to manage that budget deliberately instead of letting a session either grind to a halt or drag stale history into work that no longer needs it.
Summary
- Core Idea:
/compactcondenses a conversation's history to free space while keeping what's still relevant, while/cleardiscards the conversation entirely and starts fresh. - Why It Matters: A finite context window means unmanaged sessions eventually get crowded with old, no-longer-useful history, which can crowd out the room needed for the current task.
- Key Concepts: context window, session history, context bloat, summarization, a clean slate.
- When to Use:
/compactwhen a task is still in progress and the conversation has gotten long./clearwhen switching to something unrelated to what came before. - Limitations / Trade-offs:
/compactis a summary, not a perfect copy - fine detail can get smoothed over./clearloses everything from the old conversation, including detail you might still have wanted. - Related Topics: context window bloat auditing, CLAUDE.md persistent memory, @mentions and their context cost.
Foundations
Think of a Claude Code session's context window as a workbench with a fixed amount of surface area.
Every file you open, every command's output, and every message you send takes up some of that space.
Early in a session there's plenty of room, so nothing feels constrained.
As the conversation runs longer, though, the bench fills up with things from earlier in the task, some of which are still useful and some of which are not.
/compact and /clear are the two tools for managing that surface area once it starts to feel crowded.
/compact is like tidying the workbench: it summarizes what's there, keeps the parts that still matter, and clears away the rest, so you can keep working on the same project.
/clear is like clearing the whole bench for a new project: everything from before is gone, and you start with an empty surface.
Neither tool touches CLAUDE.md, because CLAUDE.md is not part of the conversation's history - it is project memory that gets reloaded fresh at the start of every session regardless of what happens to that session's context.
Mechanics & Interactions
The core distinction between the two commands is what happens to the conversation's prior content.
/compact produces a condensed summary of the conversation so far, and that summary - not the full original exchange - becomes the new starting point going forward.
This keeps the gist of what happened (decisions made, files touched, the state of the task) while shrinking the amount of context space it occupies.
/clear does not summarize anything. It removes the conversation history outright, and the next message starts a genuinely new session, with CLAUDE.md still loading exactly as it would for any new session.
The decision between them comes down to one question: is there still a task in progress that needs the accumulated context, or is what's next unrelated to what came before?
# still working on the same task, context is getting full:
/compact
# switching to a completely different, unrelated task:
/clearA few mechanical details worth internalizing:
/compactis a summarization step, which means some specificity is inevitably lost - a very precise earlier detail can get smoothed into a more general statement./clearis closer to closing one conversation and opening a brand new one - nothing carries forward except whatever CLAUDE.md and the files on disk still represent.- Neither command changes what's on disk - they only affect what's present in the conversation's context.
- Because both commands operate on the session's context, running either has no effect on other, separate Claude Code sessions.
Advanced Considerations & Applications
The deeper reason these commands matter is that context bloat is rarely one dramatic event - it's usually gradual accumulation.
Large files read in full, a string of @mentions across a long session, and verbose tool output (a big test run, a long build log) all add up quietly, and by the time a session feels sluggish, a fair amount of that budget is often occupied by things that stopped being relevant several turns ago.
Recognizing why a session has gotten heavy is what makes the choice between /compact and /clear an informed one rather than a reflex.
If the bloat is incidental noise around a task that's still active - verbose output from commands you no longer need to see, exploratory searches that didn't pan out - /compact is usually the right call, since the task itself is still live and benefits from the condensed history.
If the bloat is really a sign that the current task has finished, or that you're pivoting to something the old conversation has nothing to do with, /clear is the more honest move, since dragging irrelevant history forward, even summarized, adds noise rather than value.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
/compact | Preserves the gist of an in-progress task while freeing space | Summarization can lose fine-grained detail | Long sessions on a task that isn't finished yet |
/clear | Fully resets the context, nothing stale carries over | Loses everything from the prior conversation, even useful detail | Starting a genuinely new, unrelated task |
| Doing neither | No effort required | Context keeps filling until the window is exhausted or responses degrade | Short sessions that never approach the limit |
In practice, a habit worth building is treating /clear as the default between unrelated tasks - much like closing a browser tab you're done with - and reaching for /compact specifically when you want to keep momentum on something still in flight but the conversation has simply gotten long in the process.
Common Misconceptions
- "/compact and /clear do roughly the same thing." - They don't.
/compactpreserves a condensed version of history for an ongoing task;/clearremoves history entirely for a fresh start. - "/clear also removes CLAUDE.md." - It doesn't. CLAUDE.md is project memory, reloaded at the start of every session independent of
/clearor/compact. - "/compact is lossless." - It's a summary. Specific details can get generalized or dropped in the process, which is the trade-off for freeing up space.
- "You should wait until the context window is nearly full to use either command." - Using
/compactproactively, once a session feels long, tends to produce a better summary than waiting until things are already crowded. - "/clear is only useful when you hit an error." - It's just as useful as a deliberate habit for switching tasks cleanly, not only as a recovery move.
FAQs
What's the actual difference between /compact and /clear?
/compact condenses the conversation into a summary and keeps working from that. /clear removes the conversation history entirely and starts over.
Does /clear also remove my CLAUDE.md rules?
No. CLAUDE.md is reloaded automatically at the start of every session regardless of whether you've run /clear - it isn't part of the conversation history these commands manage.
When should I use /compact instead of /clear?
When the task you're working on is still in progress and you want to keep going, but the conversation has grown long enough that you want to free up space without losing the thread.
When should I use /clear instead of /compact?
When you're switching to a task that's unrelated to what came before, so dragging even a summarized version of the old conversation forward would just add noise.
Does /compact lose any information?
It can. Summarization keeps the gist and drops or generalizes fine-grained detail, which is the trade-off for reclaiming context space.
What actually causes a context window to fill up?
Large files read in full, a string of @mentions over a long session, and verbose tool output (long logs, big test runs) are common contributors, alongside the conversation itself.
Can I keep working after running /compact?
Yes. /compact is meant for exactly that - you keep the same session going, now with a condensed history instead of the full prior conversation.
Can I keep working after running /clear?
Yes, but you're effectively starting a new session. Nothing from the prior conversation carries forward, so anything still relevant needs to be restated or re-referenced.
Is there a downside to running /clear too often?
The main cost is losing useful context you might have wanted to keep - if you clear mid-task, you'll need to re-explain things Claude Code already understood a moment ago.
Is there a downside to running /compact too often?
Repeated compaction on an already-summarized history can compound the loss of fine detail over several rounds, since each pass condenses what's already a condensed version.
How do I know my context window is getting full?
There's no single universal signal, but a session that's been running a long time, has read several large files, or has accumulated many tool outputs is a reasonable cue to consider /compact or /clear before things get crowded.
Should I use /compact or /clear before starting a completely new feature?
/clear generally fits better - a new feature is usually unrelated enough to the prior conversation that a clean start is more useful than a condensed summary of unrelated work.
Related
- Auditing What's Eating Your Claude Code Context Window - identifying what's filling the window before deciding which command to use.
- Context Management Basics - where these commands fit among the section's core tools.
- Referencing Specific Files with @mentions - a common contributor to context growth.
- What CLAUDE.md Actually Does - why project memory survives both commands.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.