Last week Claude Code compacted my conversations 67 times. I didn't type /compact once. Every one of them was auto-compact, firing in the middle of work.
I only noticed because I wrote a small script that reads Claude Code's session logs on my Mac. The median compaction happened at 969,037 tokens. The turn right after it still carried about 106,000.
Note: I used Claude Code to help write the log script and to draft this post. The numbers come from my own machine, from 237 sessions over 7 days.
If you've wondered whether to run /compact or /clear, or why Claude Code keeps compacting your conversation, this is what I learned and the rule I follow now.
What /compact actually does
/compact asks Claude to summarize the conversation so far, then replaces the history with that summary. You stay in the same session.
The summary is written by the model, not by you. It usually keeps the goal and the recent steps. It often drops the small stuff: the exact error message from an hour ago, why you rejected an approach, which test was flaky.
You can steer it. Anything you type after the command becomes instructions for the summary:
/compact keep the failing test names, the API shape we agreed on, and the files we touched
That one habit fixed most of my "why did it forget that" moments.
What /clear actually does
/clear throws the conversation away. The next message starts a fresh context with your CLAUDE.md, settings and tools loaded again, and nothing else.
It's the cheapest thing you can do for your usage limit, because Claude Code re-sends the whole context on every turn. A clean session at 20k tokens costs a fraction per turn of one dragging 200k behind it.
The catch is obvious. If you're halfway through something, /clear forgets it.
Claude Code compact vs clear: the rule I use
Finished the task? /clear. Don't compact a conversation you no longer need. The summary of yesterday's bug is pure overhead for today's feature.
Mid-task, first time it gets heavy? /compact with instructions. One compaction with a clear "keep X, Y, Z" is fine.
Mid-task, long work, or it already compacted once? Write a handoff, then /clear. More on that below.
[[IMG1]]
Why it keeps compacting too often
The search "claude code compacting conversation too often" is real, and I was the case study. Three things caused it for me.
Long sessions. 139 of my 237 sessions ran 80 or more model turns. Those sessions produced 99% of all the context I sent that week. Auto-compact is a symptom of a session that should have ended earlier.
Big tool output. A full test run, a lockfile read, a build log. Each one lands in context and stays there. Pipe noisy commands through tail -n 40 and ask Claude to read line ranges instead of whole files.
A heavy baseline. CLAUDE.md files, MCP tool lists and skill descriptions load before you type anything. Run /context to see what your session is carrying, and you'll know how much room you really have.
Compacting 55 different sessions in a week wasn't bad luck. It was me never closing the window.
The handoff: the option most people skip
A handoff is a short note Claude writes to a file before you clear. You then start the new session from the note. It works like /compact, except you can read it, fix it, and keep it.
Here's the prompt I use. Paste it when context is above about 60%:
Write .claude/HANDOFF.md, under 40 lines, facts only:
## Goal (1-2 lines)
## Done (what is finished and verified)
## Next (the exact next 1-3 steps)
## Key files (paths and line numbers, no contents)
## Gotchas (decisions made, what failed and why)
Then run /clear and start with:
Read .claude/HANDOFF.md and continue from "Next".
The new session starts at your baseline plus about a thousand tokens. Compare that with the 106k my sessions carried after an auto-compact.
The note is also better than a summary in one way that matters: it records why. "We tried caching in Redis, it broke the tests, don't do it again" survives a handoff. It rarely survives a compaction.
Common mistakes (I made all of them)
Compacting twice in a row. A summary of a summary loses detail every time. If you're about to compact a second time, write a handoff instead.
Clearing mid-debug. You lose the stack traces and the list of things you already ruled out. Write the handoff first, even a five-line one.
Turning auto-compact off and forgetting. You can disable it in /config. Then you hit the context limit and the session just stops being useful. If you turn it off, watch your context percentage instead.
Not looking at the number. Put context usage in your status line. Claude Code passes the percentage to status line scripts, so you see 60% coming instead of meeting a compaction at 95%.
How to check your own numbers
Claude Code stores every session as a JSONL file under ~/.claude/projects/. Each compaction is logged as a line with "subtype": "compact_boundary", and it records how many tokens the session had before it.
This one-liner counts your compactions:
grep -h '"compact_boundary"' ~/.claude/projects/*/*.jsonl | wc -l
If that number is high, your sessions are too long. That's the whole diagnosis.
What I use now
I got tired of pasting the handoff prompt and writing status line scripts on every machine, so I packaged my setup. Full disclosure: I built it and sell it.
It includes a /handoff command that writes the note and reloads it after /clear, a status line that warns at 60% context, a hook that blocks junk file reads, and an audit script that prints numbers like the ones in this post. Everything above works without it. If you want it set up in two minutes, it's the Claude Code Limit Saver Kit.
The short version
/clear when the task is done. /compact once, with instructions, when it isn't. After that, write a handoff and start clean.
Run the grep above and tell me your count in the comments. Mine was 89 all-time, 67 of them last week, and I'd like to know if I'm the worst.
Originally published on Medium.
Top comments (0)