Claude Code /compact vs /clear: One of Them Needs Quota

When context gets heavy you either summarise it with /compact or throw it away with /clear, and the advice I kept finding was a shrug. One commenter on the compaction issue thread put the fork exactly as I experience it: keep an eye on the percentage, and then "either /clear and start over, or manually compact at a convenient place where I know it'll be effective."

So I went to the one source I have that nobody else does: 1,783 session transcripts in ~/.claude/projects. I censused every compaction and every clear in them. The answer turned out to be sharper than "it depends", because only one of the two commands can fail.

What is actually in 1,783 transcripts

Very little, is the first finding. Across the whole corpus there are 3 compact_boundary records, in 3 different sessions, which is 0.17% of them. All three carry "trigger": "manual". I have never had an automatic compaction, not once, because those sessions ran on the 1M context window and the largest one I ever grew was 469,417 tokens, nowhere near where the auto-compact threshold sits.

Two counting traps cost me a pass each. My project directories start with a hyphen (-Users-sg-mini-GitHub-mmm), so grep */*.jsonl reads the path as flags and reports zero transcripts. And a naive search for <command-name> counted six /compact calls, two of them my own live session echoing the string back in its Bash output. Filtering to genuine user commands leaves 4 real /compact calls and 6 real /clear calls.

The three compactions, measured

Session	Before	After	Dropped	Took	Verbatim messages kept
5f20ba79	469,417	8,434	460,983	155,222 ms	10
27aa5f72	208,749	11,772	196,977	143,634 ms	10
9c3e153d	462,763	11,054	451,709	139,720 ms	7

Between 1.8% and 5.6% of the context survives, and each run took between 139.7 and 155.2 seconds. That is the number I did not have before: a compaction is a two and a half minute pause, three times out of three.

The metadata also corrects something I had assumed. Alongside the summary, compactMetadata carries a preservedSegment and 7 to 10 preservedMessages uuids, so compaction is not summary-only: it keeps a tail of your recent messages verbatim and puts the summary in front of them. preCompactDiscoveredTools is how deferred tool schemas survive the boundary (13 of them in one case).

The measurement that decides it

/clear, by contrast, is not a model call at all. I timed all six from the command record to the local_command record that answers it: 286, 297, 342, 348, 372 and 422 milliseconds. Every one of them wrote an empty string as its output. No summary, no tokens, nothing to generate. Against the slowest clear, a compaction is 331 to 543 times slower.

And then there is the record that turned this from a cost comparison into a rule. In session 27aa5f72 on 2026-08-10 I typed /compact at line 887 and got no boundary. The next line of the transcript says:

<local-command-stderr>Error during compaction: You've hit your weekly limit · resets 6pm (Asia/Seoul)</local-command-stderr>

A /login follows 107 seconds later, which is me trying the wrong fix. Read that error again though, because it describes a state I had not known was possible: a context too full to work in, and an escape hatch you cannot afford. Compaction is a model request, so it draws on the same quota the work does. When you are out, the thing that would free your context is the thing you cannot run. Three of my four /compact calls completed; the fourth hit this. No /clear in the corpus has a failure record of any kind, because there is nothing in it to fail.

The docs say this plainly and my numbers are just the price of the sentence: "/compact reads the conversation it summarizes, so compacting a large context is itself a large request. When you want a fresh start instead of continuity, /clear costs nothing." The prompt caching page gives the mechanism: Claude Code "sends a separate request with the same system prompt, tools, and history as your conversation, plus a summarization instruction appended as a final user message."

What each one keeps

The difference is continuity, and the docs have a precise table for it under what survives compaction. Some of it surprised me: afterwards Claude Code re-reads up to five of the most recently modified files, and any file over 5,000 tokens comes back as a path reference rather than content. Skill bodies are re-injected but capped at 5,000 tokens each and 25,000 total. Context a hook added earlier is summarised away with the rest.

Both commands reload CLAUDE.md and auto memory from disk, which is the one thing they share. If you have edited CLAUDE.md mid-session, either command is what makes the edit take effect.

What compaction loses is the part the community complains about, and the complaint is specific. The author of the compaction issue on GitHub pasted about 8K of DOM markup, worked for forty minutes, and then "compaction fired and the summary said 'user provided DOM markup' but the actual content was gone." Another commenter avoids it on principle: "it is pretty rare for me to compact, even if i let it run to 160k". A third states the lesson I now agree with, that chat is ephemeral and anything you care about belongs on disk.

Two things about /clear that are not what I expected

First, /clear does not start a new transcript file. The docs describe it as starting a new session, and the /usage Session block does reset, but on disk the session id is unchanged and the same file keeps growing: 1,527, 490 and 377 records appended after the clear, across versions 2.1.220, 2.1.227 and 2.1.258, with no sibling transcript within five minutes. One file cleared on 07-29 kept appending until the next afternoon. Clearing frees your context, not your disk; the 30-day cleanup removes the history, not the clear. One honest limit: all six of my real clears sit at line 8 to 10 of their file, typed right after opening, so this corpus cannot say what a clear does to a large conversation already on disk. /compact is the opposite, always typed deep in: lines 887, 1360, 3143 and 3347.

Second, and this one matters if you parse transcripts for anything, a compaction makes the JSONL non-chronological. In all three files the boundary record sits exactly three lines before the /compact that caused it, while carrying a later timestamp:

Line	Timestamp	Record
3344	09:18:57.553	compact_boundary, "Conversation compacted"
3345	09:18:56.619	the summary, isCompactSummary: true
3346	09:16:21.399	local-command-caveat
3347	09:16:21.399	<command-name>/compact</command-name>
3348	09:18:57.652	"Compacted (ctrl+o to see full summary)"

Line 3345 to line 3346 jumps 2 minutes 36 seconds backwards. The boundary's parentUuid is also null, with lineage moved to logicalParentUuid, so a parent-chain walk breaks there too. Anything reading a transcript in line order will mis-order events around a compaction, which is the kind of quiet error that double-counted my token usage by 2.3x once already.

How I decide now

I expected the answer to be about how much context is worth saving. It turned out to be about whether the next thing I do is related to the last thing.

• Different task: /clear. It costs 300 milliseconds and cannot fail. There is no case where summarising context you are about to stop using is worth 146 seconds.
• Same task, and I need the thread: /compact, at a break I choose rather than one it chooses for me, with instructions (/compact focus on the auth bug fix) so the summary keeps what I know matters.
• Running low on quota: /clear now, before the choice is taken away. This is the one my August transcript taught me. Compaction needs the same budget the work does, and the weekly limit does not warn you first.
• Abandoning a path entirely: neither. The docs point at /rewind, which truncates back to a prefix that is already cached instead of building a new one.
• Anything I want to keep: on disk, before either command. A summary that says "user provided DOM markup" is not a record.

The counts come from a census of the 1,783 session transcripts in ~/.claude/projects on this Mac mini, read on 2026-09-25: 3 compact_boundary records, 4 genuine /compact calls and 6 genuine /clear calls. Durations come from compactMetadata.durationMs and, for clears, from the gap between each command and its own local_command record. My live session and an earlier one that had echoed these command strings into its output were excluded by hand, which is why the genuine counts are lower than a plain grep gives. The numbers are small on purpose: three compactions is three, not a benchmark, and my zero automatic compactions say something about 1M-window sessions that never filled rather than about auto-compaction generally. The weekly-limit failure is one observed instance, from 2026-08-10. Quotes are from the docs pages linked above and from issue 26771 and its Hacker News thread, where one commenter reports that recent versions leave a pointer to the original transcript after compacting; I saw no such pointer in my three boundaries and am not claiming it either way. The docs also moved during this research: docs.claude.com/en/docs/claude-code/* now returns 301 to code.claude.com/docs/en/*.