When to use /context, /compact and /clear

The conversation has been going for a while. You've already rejected one approach and explained why, and ten messages later the agent proposes exactly the same thing. The first impulse is understandable: wipe it all and start over (we've all been there).

A rejected solution coming back is a clear signal, but not yet a diagnosis. One answer isn't enough to blame the accumulated conversation. Things look exactly the same when the task statement contradicts itself, or when the agent is looking at a version of a file from half an hour ago.

Let's go through three commands that work on the conversation itself: /context shows what's taking up the window, /compact shrinks the history down to a short summary, and /clear starts a new conversation. The syntax is the easy part. What's more interesting is choosing between them: what to save before, what to check after, and how to tell that the problem isn't the size of the conversation at all.

Find the problem first

Before you compact or clear anything, it helps to tell apart four situations. From the outside they look alike (in all four the agent "isn't listening"), but each one calls for something different.

• Missing input. Nobody ever stated the rule for how the reward is granted, and it's not in any of the files that were read. Shrinking the conversation won't invent what was never in it: you'll have to supply what's missing.
• Stale information. The conversation holds the contents of a file read half an hour ago, and the file on disk has changed since. Compacting won't help here, rereading will.
• A contradictory task statement. The chat said one thing, the saved spec says another. Decide for yourself which requirement stands, and fix the source. A file isn't automatically right just because it's a file.
• Accumulated noise. Lots of rejected options, long command output, discussion of files that have nothing to do with the task. This is where working with the context actually makes sense.

How full the window is isn't a fifth item on this list, and it doesn't explain every mistake. A high percentage on its own doesn't prove that's why the agent got it wrong, and a low one doesn't prove the conversation is fine. The order of checks is simple: the task statement, whether the files are current, whether the outputs are current - and only then the state of the conversation itself.

Look at how full the window is

If suspicion does fall on the conversation itself, check /context. The command shows what's taking up the window, broken down by category: the system part, project instructions, files that were read and command output, the messages, free space. Which information the task no longer needs is your call. The command doesn't judge what the content means, and the overall messages line won't tell you which file is the extra one.

There's no universal threshold like "above this many percent, time to compact", and the window size depends on the model and settings anyway. Look at what's in it, not at the percentage. Oh, and closing an editor tab doesn't remove what's already been read from the conversation.

Keep going after compacting

The /compact command shrinks the history down to a short summary, and you stay in the same task. Claude Code also does this on its own as the window fills up, so you run the command by hand when you want to pick the moment (e.g. before a big new chunk of work) and set the focus.

The main limitation is that what survives is a summary, not the conversation. You can't count on details outside the summary the way you count on what's in the window. And saying "keep such-and-such conditions" doesn't guarantee the summary is complete - it's a request, not a mechanism.

What to save

Before running the command, put together a short note on the task: the goal, the boundaries, the decisions made, the verified facts, the next step. A couple of minutes. But unlike your memory of the conversation, a note can be checked against the files and the output of the checks. You don't need a separate file for it, the existing task document will do.

Here's the state of a practice task about a reward being granted twice. It's an example, not a report on a check that was actually run:

Goal: in one finished match the reward is granted once; a new match allows granting it again.
Boundaries: src/reward-flow.js and the existing reward check; don't change the styling.
Confirmed: after the first grant, a second press in the same match increases the score again.
Source: the reproduction record and the initial state are in TASK_SPEC.md.
Rejected: hiding the button without fixing how the repeated press is handled.
Next step: check the handler and propose an edit; the fix and the tests are not done yet.

Pay attention to the last line. A confirmed reproduction and a finished fix are different things, and the note has to show that, otherwise after compacting "we checked it" easily turns into "we fixed it". The task document here is a practice one, swap in your own path.

Once the note has been checked, you can compact with a focus:

/compact Focus on fixing the double reward grant. Keep the goal, the boundaries from TASK_SPEC.md, the confirmed reproduction, the rejected solution and the next step. Note that the fix and the tests are not done yet.

What to check afterwards

After compacting, don't just pick up mid-sentence. First bring back into the conversation whatever has to be exact, and ask the check question:

Read TASK_SPEC.md and the current src/reward-flow.js. Briefly name the constraint and the next step. If the summary doesn't match the files, point out the mismatch. Don't change the code yet.

Check the answer against the note line by line, not by overall impression. In our example that's three checks:

• in the "Next step" line, the fix and the tests aren't reported as done;
• from "Boundaries", the ban on touching the styling is still there;
• and the new-match condition from "Goal" hasn't gotten lost along the way.

The agent will phrase things its own way, and that's fine. If a condition has gone missing, bring it back from the source before any edit. Keep in mind that what you're checking here is the state of the conversation, not the code: this kind of check doesn't prove the next edit is correct.

Start a new task

The /clear command starts a new conversation without the previous messages. The files on disk and the project instructions stay, and auto memory, if it's turned on, can be used too, so "from scratch" here is about the messages. The old conversation isn't deleted: you can go back to it with /resume.

It's easy to mix it up with claude --continue, even though the two do opposite things. You type /clear inside a session to get away from the accumulated history. You type claude --continue in the terminal at startup to go back to the last conversation in that folder, with all of its history. If the conversation itself was the problem, --continue will take you right back into it. Not quite what you were after.

Before clearing, save whatever you'll need later: the note, the relevant paths, the check output. A new conversation needs a task statement, not a hint - the goal, the constraints and the paths. @file helps point to a specific file, just keep in mind that a mention steers what gets read, but doesn't restrict access to the other files.

Pick an action

The routine is short: stop, ask the check question, look at how full the window is if it's unclear what's taking it up, pick one action, check the result. Counting messages is pointless. what matters is what the conversation is made of and what you're about to do next.

What this changes in your work

The three commands don't fix anything by themselves. What changes is how you run a long task:

• a strange answer sends you first to the task statement and to whether the files are current, and only then to the conversation;
• before compacting or clearing there's a note checked against the files, and after compacting the answer gets checked against it line by line;
• a new task gets its own task statement, not the leftovers of the previous conversation.

You can see the difference in a single request. Before:

You're confused, let's start over.

After:

The task right now is to fix the double reward grant in src/reward-flow.js.
Read TASK_SPEC.md, name the constraint and the next step. Don't change the code yet.

The second version gets you an answer you can verify: you check the constraint and the step it names against the files and see any mismatch right away. The first one? Nothing to check it against.