"/clear kills your prompt cache" is a bad reason to avoid it

You have a session that has been open for hours, /context is uncomfortably full, and you have read somewhere that /clear is the expensive option because it throws away a warm cache while /compact preserves it. So you keep compacting, and the session keeps sprawling.

The cache mechanism behind that advice is real. The cost conclusion drawn from it is not.

What the docs actually say

The cost page puts /compact in its list of reasons usage climbs in a long session, and puts /clear on the other side of the ledger: /compact reads the conversation it summarizes, so compacting a large context is itself a large request, and when you want a fresh start instead of continuity, /clear costs nothing.

That is the whole inversion. A cache is not an asset you own; it is a discount on re-sending context you still need. After /clear there is almost nothing to re-send — the system prompt and project context reload, your first message is short, and the "lost" cache was a discount on history you deliberately discarded. Losing a discount on a purchase you are no longer making is not a cost.

The best-practices page never treats /clear as a last resort either. It tells you to reset context between unrelated tasks, and — more pointedly — that if you have corrected Claude more than twice on the same issue, the context is cluttered with failed approaches: clear, and rewrite the prompt with what you learned.

Where the correction itself overreaches

The popular rebuttal says /compact is "a large paid request that reads the whole conversation." The caching page is more precise than that, and the difference matters:

• Warm cache: the summarization request carries the same system prompt, tools, and history as your conversation plus an appended instruction, so it reads your prefix from cache. A mid-session /compact therefore costs a fraction of what the context size suggests, and spends most of its time generating the summary.
• Cold cache: after a break longer than the cache lifetime there is nothing to read, so the summarization reprocesses the full history as uncached input. This is why /compact costs the most when you resume an old session.

So "compact is expensive" is a cold-cache claim, not a general one. Both the blog and the correction of it are stating half the picture.

Choosing between the three

The rewind row is the one most people miss. If the last hour was a dead end rather than useful history, rewinding beats compacting it: the earlier prefix is still warm, because every turn since then read through it.

What is unverified here

Nobody has run a controlled comparison for this entry. What is documented is the direction of each effect, not a number:

• That /clear costs nothing and /compact reads what it summarizes: stated on the cost page.
• That a warm /compact reads its prefix from cache and a cold one does not: stated on the caching page.
• The actual dollar or token delta between "compact a 150K-token session" and "clear and re-establish": not measured, by the docs or by us. It depends on your model, your plan's cache TTL, how much of the discarded context you end up re-reading afterward, and how long the summary is.

The originating write-up is a community blog post, not a reference. Treat its prefix-mechanics section as correct and its cost ranking as the part the docs overturn.

What would settle it

Measure it on your own machine rather than trusting either write-up. Point your status line at the prompt_cache object and cost.total_cost_usd, take a large session, /fork it so you have two copies of identical context, then run /compact in one and /clear in the other and compare the cost delta over the next few turns. The /usage cache line reports misses, expected rebuilds, and whether the prefix is warm, which is what separates the warm and cold /compact cases above.

Three version gates sit on that recipe, and each one changes what you would be measuring:

• /fork copies the session only from v2.1.212. The command reference says that "on v2.1.161 through v2.1.211, and whenever agent view is turned off, /fork starts a forked subagent instead" — which inherits your context but is not a second session you can /clear.
• The /usage cache line is newer still. costs.md says the Prompt cache (main) line "Requires Claude Code v2.1.251 or later". Below that you are reading raw token counts, not a warm-or-cold verdict.
• cost.total_cost_usd resets to zero when /clear starts a new session — but only recently: "Before v2.1.211, they kept accumulating across /clear for the lifetime of the Claude Code process." On a current client, record the pre-clear total first or the clear branch looks free for the wrong reason; on an older one the totals never reset and the comparison silently measures something else.

Checkpoint

1. Why is "cache hits drop to zero" not the same as "this action costs you money"?
   ›Show answerAnswer

   Because a cache is a discount on re-sending context you still need, not an asset you own. After /clear there is almost nothing left to re-send — the system prompt and project context reload, your first message is short — so the discount you lost applied to history you deliberately discarded, and losing a discount on a purchase you are no longer making is not a cost. The cost page says it outright: when you want a fresh start rather than continuity, /clear costs nothing, while /compact sits on its list of reasons usage climbs in a long session.

2. Under what condition is /compact genuinely a large paid request, and under what condition is it cheap?
   ›Show answerAnswer

   Cold cache makes it expensive: after a break longer than the cache lifetime there is nothing to read from, so the summarization reprocesses the full history as uncached input — which is why /compact costs most when you resume an old session. Warm cache makes it cheap: the summarization request carries the same system prompt, tools and history plus an appended instruction, so it reads your prefix from cache and spends most of its cost generating the summary. Both halves come from the caching page, which is why "compact reads the whole conversation and is therefore expensive" is a cold-cache claim dressed up as a general one — the originating blog and its popular rebuttal each hold half the picture.

3. You went down a dead-end path for the last hour and want it gone. Which of /clear, /compact, /rewind is cheapest, and why?
   ›Show answerAnswer

   /rewind. It truncates back to a prefix the cache already holds — every turn since then read through that prefix, so it is still warm — instead of building a new one. /compact would pay to summarize an hour you have already decided is worthless, and /clear would take the useful history before the dead end along with it. Keep the hedge in view: the actual token delta between these has not been measured, by the docs or here, so decide on relevance first and let the arithmetic follow.