Introduction

Long coding sessions get heavy. After enough file reads, test runs, explanations, and side discussions, the assistant starts carrying a lot of history. That history costs tokens and can make the session harder to steer.

/compact is a way to reduce that weight. In Claude Code, the command compacts the conversation, optionally with extra instructions about what to preserve. Similar tools use the same general idea even if the command name is different: summarize the useful parts of the session and continue from the summary instead of the full transcript.

What compaction does

Compaction is not magic memory. It is a lossy summary.

The tool takes the current conversation and turns it into a shorter representation of what seems important:

• The goal
• Decisions already made
• Files touched
• Commands run
• Current blockers
• User preferences
• Remaining tasks

After that, the model continues with the compacted version as context. This reduces token usage, but the details that are not included in the summary are effectively gone from the active conversation.

A practical example

Suppose you have a long session like this:

We investigated failing integration tests.
We found the issue in LinkService.
We changed validation around custom slugs.
We ran unit tests.
Integration tests still fail because the test database is missing a migration.
Next step: inspect migration setup.

A good compacted summary keeps those facts. A bad one might only say:

We worked on tests and validation.

That is too vague. The assistant can continue, but it may rediscover things or make worse assumptions.

When to use /compact

I would use it when:

• The session is long but still about the same task.
• The assistant starts slowing down or losing focus.
• You are close to context limits.
• The tool suggests compaction automatically.
• You want to continue tomorrow without carrying every detail.

It is also useful after finishing a phase. For example, after exploration and before implementation:

/compact Focus on the files inspected, the chosen approach, open risks, and commands already run.

That gives the next part of the session a cleaner starting point.

When not to use it

I avoid compaction in the middle of delicate debugging. If the exact error output, line numbers, or sequence of events matters, I would rather finish that investigation first.

I also avoid it right after giving nuanced instructions. There is always a chance the summary preserves the general idea but loses the tone or constraint that mattered.

For example:

Do not change the public API.
Keep this compatible with the existing mobile client.
Do not touch the migration files.

If those constraints matter, repeat them after compaction. It is cheap insurance.

Pros and cons

The main benefits are simple:

• Less context to carry
• Lower token usage
• Cleaner continuation
• Fewer old details competing for attention

The main downsides are also simple:

• Details can be lost
• The assistant may forget why a decision was made
• Subtle constraints can disappear
• It can hide uncertainty behind a confident summary

This is why I think of /compact as a checkpoint, not a save file. It preserves enough to continue, but not everything.

My rule of thumb

Use /compact when the session has accumulated useful history, but the exact transcript is no longer important.

Do not use it as a substitute for good instructions. After compaction, restate anything critical:

Continue from the compacted context.
Do not change public API contracts.
Run lint and the focused test suite before finishing.

That usually gives the assistant enough structure to continue without dragging the whole session behind it.