One session, one task

The best-practices guide keeps a list of common failure patterns. The first one on it is not exotic, and you have almost certainly done it this week:

The kitchen sink session. You start with one task, then ask Claude something unrelated, then go back to the first task. Context is full of irrelevant information. — Best practices

The documented fix is one word long: /clear between unrelated tasks. The interesting question is why something this simple needs teaching at all.

Why it is hard to notice from the inside

Switching tasks inside one session is frictionless. Nothing stops you, nothing warns you, and the second task usually starts fine — the window has room. The cost lands later and looks like something else entirely.

Recall the two facts from Lesson 3.1. The full conversation is re-sent with every request, and quality degrades as the window fills. So a kitchen-sink session fails in a way that is easy to misread:

None of these arrive labelled "your context is polluted". That is the whole difficulty: the symptom points at the model, and the cause is the session.

The two-correction rule

This is the most immediately useful specific rule in the entire guide, and it is worth memorising as written:

If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt that incorporates what you learned. A clean session with a better prompt almost always outperforms a long session with accumulated corrections. — Best practices

Notice what it is not saying. It is not "clear when you get frustrated". It gives you a countable threshold — the same issue, more than twice — precisely because frustration is a bad instrument and a count is a good one.

And notice the second half, which is the part people skip. The instruction is not simply /clear; it is clear and write a better opening prompt that incorporates what you learned. The two failed corrections were not wasted: they told you what the agent was going to get wrong. That belongs in the first sentence of the new session, where it costs 40 tokens, rather than being rediscovered across a hundred turns.

Name the thing you are leaving

/clear takes an optional argument, and it does something more useful than it first appears:

Start a new conversation with empty context. Pass a name to label the previous conversation in the /resume picker. — Commands

So /clear release-prep labels the conversation you are leaving — not the one you are starting — which is what makes it findable later. With no argument, the new conversation keeps a name you set yourself with --name or /rename, but not an automatically generated session title.

This is what removes the last real objection to clearing. "I might need that conversation" is true, and it is not an argument for keeping it in your window: the conversation is saved either way. Lesson 3.5 is about getting back to it.

The costs case, briefly

The same habit shows up in Anthropic's guidance to administrators trying to explain a surprising bill:

Unexpectedly high spend on an API or cloud-provider plan: usually traces back to long sessions that were never cleared or to Opus left as the default model. — Manage costs effectively

Two habits, and the first one is this lesson. Worth knowing if you ever have to defend the tool's cost to someone: "sessions that were never cleared" is the documented first suspect.

When to let it accumulate instead

A rule taught without its exception becomes a superstition, and the guide is explicit that this one has an exception:

Sometimes you should let context accumulate because you're deep in one complex problem and the history is valuable. — Best practices

The test is not session length. It is whether the history is about the thing you are still doing. Four hours on one gnarly race condition, where every earlier dead end informs the current hypothesis, is a session working correctly. Forty minutes covering three unrelated tickets is a kitchen sink, and it will behave like one.

When you are in the first case but the window is genuinely filling, the answer is not /clear — it is /compact with instructions naming what the next stretch needs, which is the lever from Lesson 3.2.

Checkpoint

1. You have told Claude three times not to add comments to generated files, and it has done it again. What does the documented rule say to do, and what is the second half of that instruction that most people skip?

   ›Show answerAnswer

   Run /clear. You are past the documented threshold — corrected more than twice on the same issue in one session means the context is cluttered with failed approaches.

   The half people skip is everything after the command: start fresh with a more specific prompt that incorporates what you learned. Your three corrections were not wasted; they told you exactly what the agent was going to get wrong, so "do not add comments to generated files" belongs in the first sentence of the new session, where it costs 40 tokens rather than being rediscovered across a hundred turns. A clean session with a better prompt almost always outperforms a long session with accumulated corrections.

   The trap is that a fourth correction feels cheaper than starting over, because you have already explained so much. The explanations are the problem: they are the failed approaches now sitting in the window, competing with your next instruction.

2. You are about to /clear a long debugging session you might want back tomorrow. What exactly do you type, and which conversation does the name attach to?

   ›Show answerAnswer

   Type /clear <name> — for example /clear release-prep. The name attaches to the conversation you are leaving, not the one you are starting, and it is what labels that conversation in the /resume picker so you can find it tomorrow.

   With no argument the new conversation keeps a name you set yourself with --name or /rename, but gets no automatically generated session title. Note that the conversation is saved either way — "I might need that conversation" is true and is still not a reason to keep it in your window. Naming only decides whether you can find it.

3. Describe a session that has been open for three hours and is not a kitchen sink. What distinguishes it?

   ›Show answerAnswer

   One where all three hours are about the thing you are still doing — say a single gnarly race condition, where every earlier dead end informs the current hypothesis. That is a session working correctly, and the guide is explicit that sometimes you should let context accumulate because you are deep in one complex problem and the history is valuable.

   The distinguishing test is not session length; it is whether the history is about the current task. Forty minutes covering three unrelated tickets is a kitchen sink and will behave like one, while three hours on one problem is not. If the window genuinely fills in that second case, the lever is /compact with instructions naming what the next stretch needs — not /clear.