Home › Guides › When to use /compact

When to use /compact in Claude Code

Compacting replaces the accumulated conversation with a shorter summary, so the context re-sent on every following turn shrinks. Because re-sent context dominates long-session cost, knowing when to compact is one of the highest-leverage cost habits you have.

What /compact does

Over a long session the context grows: files read, command output, and a long back-and-forth all stay resident and get re-sent every turn at the cache-read rate. /compact summarizes the conversation so far into a much smaller representation and continues from there. The practical effect on cost: every turn after the compact carries less context, so each one is cheaper.

Compacting helps going forward, not retroactively. It can't refund the turns you already paid for — it lowers the cost of the turns still ahead. So the earlier you compact a bloated session, the more turns benefit.

When to compact

  • The context has grown large and you have a lot of work left. This is the textbook case: a big context times many remaining turns is exactly what compacting cuts.
  • You pulled in big one-off context that's no longer needed. A large file or verbose log that mattered for one step is now dead weight being re-sent every turn — compacting sheds it.
  • The thread has wandered. If the early conversation is no longer relevant to what you're doing now, a summary keeps the useful gist and drops the rest.

When a fresh session beats /compact

Compacting keeps a summary of the old conversation. Sometimes you don't even want that:

  • You're genuinely starting a new task. A fresh session carries zero historical context, which is the cheapest possible starting point — nothing old is re-sent at all.
  • The session is huge and the history isn't worth summarizing. If almost nothing from earlier matters, a clean start beats paying to carry even a summary.

Rule of thumb: same task, want to keep the thread → compact. New task, or the old thread no longer matters → fresh session.

The trade-off

Compacting isn't free of downsides. The summary is lossy: details, exact file contents, and nuance from the original conversation can be dropped, so the model may need to re-read a file or re-establish something it "knew" before. That re-reading is itself new context (a cache write, then cache reads). In practice the savings on a bloated session far outweigh this, but it's the reason not to compact compulsively on a still-small context — there's nothing to gain and you might lose useful detail.

Don't compact a small, focused session just to be tidy. If the context is small, the re-sent cost is already low, and you'd only risk dropping detail for no saving.

Know when you're in the danger zone

You don't have to guess whether a session has grown large. tokenscope shows your peak and average context size and the per-turn growth curve, so you can see when context has crept up and a compact or fresh session would pay off.

npx @wartzar-bee/tokenscope Paste a report in your browser →

Read-only, local, no upload. Flags large contexts and the turns and tools driving them.