When to run /clear instead of /compact in Claude Code

Short answer: run /clear when you want a fresh start and /compact when you need continuity, because Anthropic's own documentation states that "/compact reads the conversation it summarizes, so compacting a large context is itself a large request" while "when you want a fresh start instead of continuity, /clear costs nothing". The practical rule that follows: if the next thing you are doing is a different task, clear; if it is the same task and you would have to re explain it, compact.

What is the difference between /clear and /compact in Claude Code?

The two commands solve opposite problems. /compact asks Claude Code to summarize the conversation so far and continue from that summary, keeping the thread of what you were doing. /clear ends the session and starts an empty one, keeping nothing. The cost asymmetry is the part most people miss, and it is documented on Anthropic's cost management page for Claude Code, read on August 11, 2026: compaction has to read everything it is summarizing, so the bigger the mess you are compacting, the more that single command costs you. Clearing reads nothing.

Two smaller behaviours are worth knowing before you pick. You can steer a compaction, because the same page documents that /compact followed by an instruction, in its example "Focus on code samples and API usage", tells Claude what to preserve during summarization. And compaction has a floor: in a fresh session, /compact prints "Not enough messages to compact." because there is no history to summarize yet.

When should you start a fresh session instead of continuing?

The honest answer is that most developers do not have a principled rule, and say so. A question published in the r/ClaudeCode community and reproduced in r/ClaudeCoding on August 10, 2026 puts it plainly. The developer who asked it describes his own criterion as "vibes: when it starts re-reading files it already read, or repeats a fix I rejected two turns ago, I bail and start over with a summary", adds that "compaction helps but the session is usually already degraded by the time it kicks in", and then asks the question that has no published answer: whether a long session is genuinely worse, or whether he has trained himself to blame the session when the task was underspecified from the start.

That last doubt deserves to be taken seriously rather than answered with confidence nobody has. A useful way to separate the two causes: before you clear, write down in one line what you are trying to achieve and what proves it is done. If you cannot write it, the session was not the problem, and a fresh session will reproduce the same wandering with a clean context. If you can write it easily, the context was carrying weight that no longer serves the task, and clearing is the cheap fix.

Why does a long session consume so much even when you type little?

Because the length of your message is not what gets sent. Claude Code sends the full conversation with every request, and, in the documentation's own words, "each time Claude uses tools it sends another request carrying that batch of tool results", which is why "a one-line question in a session that has been open all day still draws usage for the whole conversation". Your typing effort and your consumption stopped being related several hours ago.

There is a second effect that punishes exactly the way people work, which is in bursts with breaks in between. The same page documents that the first message after a break longer than the prompt cache lifetime misses the cache and reprocesses your full context, and that the lifetime is one hour on a subscription, dropping to five minutes once you are drawing on usage credits, with five minutes also the default on an API key or a cloud provider. Coming back to a large session after lunch is therefore more expensive than continuing it before lunch, and the documentation notes that setting ENABLE_PROMPT_CACHING_1H=1 keeps the one hour lifetime while drawing on usage credits.

Is a context warning the same as a usage limit warning?

No, and confusing the two leads people to buy a bigger plan when the fix was free. Anthropic's guidance for developers is explicit that "a context or auto-compact warning: not a usage limit", and describes it as the conversation having grown close to the session's auto compact window, the threshold where Claude Code summarizes older history to free space. That is a signal about the shape of one conversation, not about your remaining quota for the day.

The usage limit is a different event with different answers, and we wrote about it separately in what to do when you hit your AI coding agent usage limit. The short distinction worth keeping: a context warning means this conversation got heavy, and clearing solves it in one second; a usage limit means your window is spent, and no command fixes that.

What is eating your context without you noticing?

Four items from the same documentation, and none of them involve you typing. Scheduled tasks fire on their interval even while the session is idle, sending your full context each time. Cross session messages are delivered as a new turn when the session sits idle, also sending the full context, and can be held instead by setting crossSessionInbound to hold. Agent teammates keep consuming tokens until they exit. And MCP servers add weight through their tool listings, which is why the documentation defers MCP tool definitions by default and recommends preferring CLI tools such as gh, aws, gcloud and sentry-cli, which add no per tool listing at all.

This is the strongest argument for clearing rather than compacting when you walk away from a task: an idle session is not a free session. If something else can push turns into it, leaving it open all afternoon has a running cost that a summary does not remove.

How do you see what is filling the context?

Claude Code answers this directly with /context, which the documentation describes as showing what is consuming space. On a Pro, Max, Team or Enterprise plan, the /usage breakdown goes further and flags behaviours that account for 10% or more of your recent usage, such as long context or cache misses, each with a tip to reduce it. Between the two, the guessing stops: you find out whether the weight is your conversation, your skills listing, or your MCP servers before deciding which command to run.

Being precise about what our own tool does and does not do here: CanvasCode, the Mac app that runs the official agent CLIs side by side on one canvas, shows a usage ring per account, a feature in the app since CanvasCode version 1.12 in June 2026, and that answers how much of your plan is left, not how heavy the current conversation is. For the second question, /context inside Claude Code is the right instrument, and we do not replace it.

How do you clear without losing the thread?

Claude Code has a documented pair for this: use /rename before clearing so you can find the session later, then /resume to return to it. Beyond that, the habit that works is writing the handoff yourself, or asking the agent for it, before you clear: what the task is, what was decided, what is done, what comes next. You keep the decisions and drop the token weight of how you reached them.

We run our own content pipeline on exactly this shape, which is our evidence rather than an opinion. It executes three times a day on this site, and each execution starts with no memory of the previous one. What crosses between them is written down instead of remembered, in two separate places: a field notebook of curated conclusions, capped at 300 lines and holding 216 lines on August 11, 2026, and a log of the actions each run took with the reason for each one. Three cold starts a day work because the handoff is written, not because the sessions are long. One caveat we cannot resolve for you: Anthropic does not publish the token threshold at which auto compaction fires, so nobody, including us, can tell you the exact size at which clearing beats compacting. What you can do is watch /context and treat the two commands as answers to different questions.