/clear vs /compact in Claude Code: Choosing the Right Reset for Long Sessions

If you have spent half a day inside a single Claude Code session, you have probably hit this moment: "I think we should reset, but I really don't want to throw away the context we just built up." That is the moment where /clear and /compact start sounding awfully similar — and that is where I have made the most mistakes.

I have lost meaningful work to /compact summarizing away a critical file path. I have also dragged a polluted session through an extra two hours when I should have just /clear-ed and started fresh. So here is what I have learned about choosing between them, written down in the form I wish I had read before that first painful afternoon.

Why these two commands feel interchangeable (but aren't)

If you read the descriptions side by side, they sound like dimmer switches on the same lamp.

• /clear wipes the conversation history entirely. The next turn behaves like a first message. CLAUDE.md is reloaded, so your project-wide context is rebuilt from scratch.
• /compact summarizes the conversation into a short recap and continues from there. Long histories shrink to a page or two and you keep going.

The trap is the assumption that "if /compact keeps information, it must always be safer." It isn't. What /compact keeps is Claude's summary of the conversation, not the raw words. Specific file paths, exact numbers, and rejected options frequently get smoothed over.

So while both commands narrow the context, the quality of what's preserved is fundamentally different. If you don't pick the right one for the right reason, the next half hour of work pays the price. The asymmetry also matters because of how Claude reads its own context: a clean session is a fresh, sharp reading; a compacted session is reading a digest of itself, which carries the bias of whoever wrote the digest — even when that "whoever" is the same model.

When /clear is the right call

I reach for /clear in three situations:

• The conversation explored a wrong direction. I spent five turns debating two libraries and chose one — but the rejected option keeps surfacing in suggestions because it is still in the history. /clear puts that to rest.
• The task itself has changed. Backend refactoring in the morning, UI tweaks in the afternoon. The morning context isn't useful — it is friction.
• I am stuck in a debugging loop. If we have circled the same error three times, Claude has internalized "this error is hard." A clean slate often solves it in one shot.

The reason /clear is not scary in those situations is CLAUDE.md. Project-level context — language, directory layout, conventions — is read fresh after every clear, so the genuinely persistent knowledge survives. If you want to make /clear even safer, CLAUDE.md design and productivity — writing the project's DNA is where I would start.

One subtle benefit of /clear that took me a while to appreciate: it gives Claude permission to disagree with the previous direction. After a long debate, the model has a strong implicit prior that the conclusion was correct. A clean session looking at the same code often surfaces a concern you talked yourself out of an hour ago.

When /compact is the right call

I reach for /compact in different situations:

• A long design discussion has just concluded and I need to start implementing. Thirty turns of architecture work just landed on a decision. /clear would erase the decision; /compact keeps it.
• A multi-file refactor is in progress. I am editing files A, B, C and still have D and E to go. The "what changed where" memory is genuinely useful to keep.
• A test-driven cycle is mid-flight. Test intent and implementation progress need to stay paired, otherwise the refactor phase loses its anchor.

A nice property of /compact is that Claude itself reads the summary before the next response, which means a poor summary is something Claude is aware of. After every /compact, I make a habit of asking, "Is there anything important the summary dropped?" The answer is sometimes very useful — and on a few occasions it has caught issues I hadn't noticed myself.

The real failure modes of /compact

Here is what bit me before I figured this out:

• Concrete file paths get abstracted. I was editing src/lib/auth/sessionStore.ts's validateRefreshToken — the summary preserved "the authentication refresh-token handling." The next request opened the wrong file.
• Numbers and thresholds round off. "Set the timeout to 8000 ms" became "an appropriate timeout" in the summary.
• Rejected options come back. When the discussion concluded "Plan A rejected for performance reasons; go with Plan B," the summary kept Plan B but lost the rejection rationale. A few turns later, Plan A reappeared as a suggestion.
• Tooling state is harder to recover than you think. Things like "we already enabled the staging API key for this session" or "you previously tried pnpm install --frozen-lockfile and it failed with X" tend to vanish, and the model can re-suggest the same failed step.

My fix for the first three is a one-liner before pulling the trigger:

Before /compact, please make sure the summary includes:
- Architecture chosen: event sourcing + CQRS
- Rejected: simple REST with direct DB writes (reason: cannot satisfy audit-log requirement)
- File currently being edited: src/domain/order/aggregate.ts
- Remaining work: tests in events.ts, implementation in infra/eventStore.ts

That single instruction noticeably improves what survives the compaction. For the fourth — tooling state — I take a different approach: I let it disappear on purpose, because relying on Claude's memory of a transient command result is more fragile than re-checking. After /compact, I prefer to re-run a quick git status or pnpm test rather than trust the recap of an earlier output.

The three questions I ask before deciding

When I am genuinely unsure, these three questions resolve almost every case:

1. Are the assumptions from this discussion still useful going forward? Yes → /compact. No → /clear.
2. Does CLAUDE.md already capture the project's persistent context? Yes → /clear is low risk. No → /compact is safer until you fix CLAUDE.md.
3. Have we looped on the same topic three or more times? If yes, /clear wins almost every time.

The third one is the hardest to ask honestly. I have started stepping away from the keyboard for a moment when I suspect a loop, and deciding only after coming back. Without that pause I tend to "just push through" — and then loop one more time.

A practical signal that you have been looping: if you find yourself re-explaining context that you definitely already explained, the model is signalling that the most recent context isn't serving you — either it is buried under noise (/clear) or the summary lost it (re-state it explicitly, then /compact if you want to keep going). Treat that re-explanation reflex as a diagnostic, not a chore.

If you want a sharper read on when /compact should fire, Claude Code token usage visualization and limit management gives you a way to see the runway you actually have left.

Making /clear cheap by leaning on CLAUDE.md

/clear becomes a low-cost move once CLAUDE.md is doing real work. Three patterns that have paid off for me:

• Add a "Current work in progress" section to CLAUDE.md, e.g. ## Current branch: feat/payment-v2. Day-to-day context survives /clear because CLAUDE.md is reloaded.
• Separate "must-follow" rules from "preferred" rules. The hard rules go first so Claude obeys them immediately after a clear, with no ambiguity.
• Park important decisions in a separate file like _decisions.md and link to it from CLAUDE.md. Claude opens it only when needed, but it is always available.

A small operational tip: I keep one line at the very top of CLAUDE.md that says "If you just rejoined a /clear-ed session, briefly tell me where you think we are before doing anything." Two sentences from Claude tell me whether the reload landed correctly. If something important didn't come through, I add it to CLAUDE.md and never lose it again.

For a deeper look at keeping a long session healthy, keeping context honest in long Claude Code sessions walks through the patterns I rely on most.

There is no universally correct answer between /clear and /compact. The skill is reading the current session and noticing whether it has accumulated noise or accumulated value. The next time you hesitate at that fork, run the three questions once. The decision tends to take a fraction of the time it used to.