Context Management: /clear, /compact, /btw, and Checkpoints

The Kitchen-Sink Session

You start a session to implement a feature. Halfway through, you get curious about an unrelated part of the codebase and ask Claude a few questions. Then you return to the feature. Then you ask Claude to help debug something else entirely. By turn forty, the context window contains half-implemented feature code, tangential exploration results, debugging output from an unrelated issue, and multiple partial corrections from your redirections. Claude is trying to hold all of this in working memory while you ask it to complete the feature.

This is the kitchen-sink session — starting one task, mixing in unrelated work, returning to the original task — and it is one of the most common causes of degraded Claude performance in long sessions. The fix is straightforward but requires discipline: clear context between unrelated tasks.

/clear Between Unrelated Tasks

/clear resets the context window entirely. The conversation history is gone. File reads are gone. Command outputs are gone. Claude starts fresh, with only the session startup context (CLAUDE.md, auto memory, system prompt) that would be present at the beginning of any session.

Use /clear whenever you shift to a genuinely different task. Not between related subtasks within the same feature — between entirely different concerns. Finished implementing the OAuth flow and now want to look at a performance issue in the database layer? Clear. Fixed the bug and now want to review a PR? Clear. The context from the previous task is not just irrelevant — it actively competes with the new task for Claude's attention.

After the second failed attempt to correct Claude on the same issue, clear is the right move. If Claude has made the same mistake twice and two rounds of correction have not fixed it, the context is too polluted with failed approaches. Starting fresh with a better initial prompt that incorporates what you learned from the failed attempts almost always works better than continuing to correct in a corrupted context.

/compact with Custom Instructions

When you do not want to lose all context — you are deep in a complex problem and the accumulated file reads and partial implementations are genuinely valuable — use /compact instead of /clear. /compact runs automatic compaction, summarizing earlier parts of the conversation while preserving recent context.

The power of /compact comes from custom instructions. When you run /compact Focus on the API changes we've been making, the summarizer prioritizes that content and compresses everything else more aggressively. You preserve what matters and compress what does not.

For recurring compaction needs, embed the instructions in CLAUDE.md: "When compacting, always preserve the full list of modified files and any test commands that were run." These hints load at session start and inform every compaction event, including auto-compaction.

What Survives Compaction

After compaction, the context window contains a summary of the earlier conversation plus recent messages in full. Some things survive reliably; others do not.

Project-root CLAUDE.md files survive compaction. After /compact runs, Claude re-reads the project-root CLAUDE.md from disk and re-injects it into the context. Your CLAUDE.md instructions are always available after compaction.

Nested subdirectory CLAUDE.md files do not automatically re-inject after compaction. They reload the next time Claude reads a file in that subdirectory. If you were working deeply in a subtree-specific context and compaction fired, the subdirectory CLAUDE.md re-enters context the next time Claude reads a file there.

Instructions given only in conversation — not in CLAUDE.md — do not survive compaction. If you told Claude something important in turn three and compaction fired at turn fifty, that instruction may not be in the summary. This is the main reason to add important instructions to CLAUDE.md: conversation-only instructions are ephemeral.

/btw for Side Questions

Sometimes you want to ask Claude a quick question without the answer cluttering your main conversation context. /btw is built for this. It opens a dismissible overlay where you ask your question, Claude answers, and the entire exchange disappears without entering conversation history.

Use /btw for quick lookups that would otherwise generate noise in context: checking a function signature before you use it, asking what a particular error code means, getting a quick syntax refresher. The answer is visible when you need it and does not add to the context token count when you close the overlay.

The Two-Correction Rule

When Claude makes a mistake and you correct it, the correction enters the context. If Claude makes the same mistake again and you correct it again, a second correction enters context alongside the first. By the third occurrence, context contains multiple versions of the correction, Claude's intermediate states between corrections, and accumulated ambiguity about which version of the rule to follow.

The two-correction rule: after correcting Claude twice on the same issue without lasting improvement, stop correcting and start over. Clear the context, write a better initial prompt that makes the constraint explicit from the beginning, and start fresh. The problem is usually not Claude's capability — it is that the context has become too confused for any correction to hold reliably.

/rewind and Checkpoints

Every prompt you send creates a checkpoint. If a series of changes goes wrong — Claude took your codebase in a direction you did not intend, made a change that broke something, or implemented the wrong feature — you can rewind to any earlier checkpoint without losing all your progress.

Double-tap Escape or run /rewind to open the rewind menu. From there you can restore the conversation history only (useful when the code changes are fine but the conversation context went wrong), restore the code files only (useful when you want to keep the conversation but undo specific file changes), or restore both. You can also choose a checkpoint and summarize from there — condensing the earlier conversation into a summary while keeping the recent context intact.

Checkpoints persist across sessions. You can close Claude Code, come back the next day, and still rewind to a checkpoint from yesterday's session. This makes it safe to try risky approaches: if the approach does not work, you have a clean restore point. Claude Code tracks changes made by Claude, not changes made by external processes — checkpoints are not a replacement for git, but they are a useful complement for the changes Claude makes during a session.