Clear once the work is done and whatever comes next is unrelated. Compact, with a focus text, when the same task must go on but the context has grown heavy. Finish the current step first when a deploy or a migration has not been checked yet. Otherwise keep going. Before any fresh session, write down whatever exists only in the conversation, because the new session starts empty. Do not wait for auto-compact: on a model with a native 1M window it does not trigger before about 967 000 tokens (model configuration). And the agent cannot type the command for you, so its job is to save everything and then hand you the exact line to enter.

Method

For the documented side we went through 25 pages of Anthropic's Claude Code docs for version 2.1.301, on 16 October 2026. Where a page was silent, we searched it for the likely words and say so below.

The size figures come from our own machine in October 2026: two long working sessions of one person, and one live session where a reminder hook fired. We took a session's size from its transcript, never from the model's own account.

For the test we wrote 30 snapshots of a session. Each lists the context size, the state of the task, git status, running processes, the plan file, earlier corrections and the person's request. Twenty-five hold one planted problem and 5 hold none. Sonnet and Haiku answered every snapshot once, with a reviewing skill and without it. With the skill, code scores the exact set of findings and the closing decision line. Without it, phrase checks score the same points. We read every failure of the second run by hand, and afterwards widened seven no-skill checks so that they accept the same point put in other words. That favours the no-skill side, and a different scorer could move a result.

Results

What the two commands do, per the docs

/clear opens a new, empty conversation and loads project memory again. You can reopen the old conversation with /resume, yet the new session starts without it (commands). That is why saving comes first: what was only said in the chat is gone afterwards.

/compact summarizes the conversation and accepts an optional focus text. The memory file CLAUDE.md can hold a Compact Instructions heading with the default focus. After compaction the root CLAUDE.md and the auto memory are re-injected from disk, up to five recently used files are read again, and early detailed instructions can disappear (context window). Background commands keep running through it. The pages we searched do not say whether background tasks survive /clear, and we did not test it.

Auto-compact is late and unannounced

The default point is the model's limit: about 967 000 tokens with a native 1M window, and the 200K boundary for the 4.6 models without extended context (model configuration). We found no documented warning before it fires; the pages describe only the capacity warnings in /context. An idle compaction exists too: it summarizes a session you walked away from just ahead of the cache running out.

So the moment is picked by a counter. It can land partway through a step, and it comes with no focus text at all.

The agent cannot run it

The skills page lists /compact among the built-in commands that the Skill tool cannot run (skills). /clear is not mentioned there. An agent that promises to clear the session itself is promising something the docs do not give it. What it can do is save the work, then say the line.

What a long session costs

In a project whose memory is large, the first request on our machine already carried about 90 000 tokens. One session then reached 835 000 tokens and another 522 000, so a late message dragged along about nine and six times the starting load. The docs explain why that matters: every request sends the whole conversation, so even a short question late in a day-long session counts against your usage for all of it (costs).

The cache softens this only while it is warm. It lives an hour with a subscription and five minutes on an API key or usage credits, and the first message following a longer pause reprocesses everything (prompt caching).

In one live session a hook that reminds the person about size fired once the count passed roughly 164 000, and that session was saved and cleared. To see the size, use /context, or read the status line, whose used_percentage field is built from input tokens alone (status line). Do not ask the model. As we showed in an earlier post, what a model says about its own context is testimony, not a measurement.

Repeated corrections

The best-practices page gives one more trigger: after a third correction of the same mistake, clear, then restart with a sharper prompt (best practices). Every failed attempt stays in the context that the next attempt reads.

What the models did with 30 snapshots

Sonnet decided 30 of 30 snapshots right with the skill; without it, 28 of 30. Haiku scored 29 against 26. This was the second full pass: the first led us to edit the skill text and the common request, and then all 120 runs were repeated, plus 4 more after one snapshot was reworded.

Bare Sonnet already did most of the job. It held back a fresh session for results that lived only in the chat, no recorded next step, work not yet saved, running background processes and a secret about to land in the plan. It waited on an unchecked deploy and a migration, measured the size instead of guessing it and picked /clear over /compact for finished work.

It slipped twice. With one task finished and an unrelated one next, it stayed in the same session of 60 000 tokens, where the docs advise a clear between unrelated tasks (costs). And asked to commit all that git status listed, it included two files that another session had changed. When several sessions share one folder, that commit puts someone else's change, possibly unfinished, into your history under your message. The better answer leaves those files out and tells the person.

Haiku without the skill made three different errors. It chose /clear before anyone had checked a green deploy on the live site. It missed an uncommitted file beside a running watch process. And in two snapshots where the project folder was read-only, it named a writable place from its own environment rather than the session it was reading about, then chose /clear although only /compact with a focus text would have kept the findings. With the skill, its one miss was a false report of uncommitted work on a clean tree.

The skill is claude-session-saver. The snapshots and the scoring are ours.

What we did not measure

  • The snapshots are ours. They describe sessions rather than being real ones: the model reads pasted text and cannot see the true size, the cache state or running processes.
  • A single run for each model and case. A repeat might shift one result.
  • Seven checks were widened after we read the failures. Another scorer could land a point or two away, in either direction.
  • One machine, one version. Windows and Claude Code 2.1.301. Thresholds and defaults change, so if a docs page and this post differ, trust the page.
  • Quality loss in long sessions is the docs' claim. We did not measure it.
  • /clear and background tasks. The docs are silent and we did not test it.
  • Tokens, not the weekly limit. We did not measure how they count against a plan allowance.
  • Two big sessions of one person. The two peaks, 522 000 and 835 000 tokens, show that it happens, not how often.

Read this post as Markdown: /blog/claude-code-clear-or-compact.md · Atom feed.