Claude Code /compact: how to manage context and cut costs in long sessions
When a Claude Code session runs for hours, responses eventually start to degrade: the assistant forgets a decision made early on, re-reads files it already processed, spins its wheels. Almost always the cause is the same — the context window has filled up. The /compact command exists precisely for this: it summarises the conversation and reloads it as a fresh starting point, keeping what matters and discarding the rest. In this article I look at what /compact does under the hood, why auto-compaction sometimes fires at the wrong time, and the exact workflow I follow every day to stay sharp and spend less.
🔍 What /compact does and why context is the real bottleneck
The context window is the space where Claude Code holds everything: conversation history, open files, command output, CLAUDE.md, loaded skills, and system instructions. As I work, that space fills up. When it is full there is no room left to reason: context is the scarce resource, not the model's intelligence.
The /compact command takes the conversation, summarises it, and replaces the long history with that summary. It is different from /clear, which wipes everything and starts from zero. With /compact I keep the thread — key requests and important code snippets stay — while with /clear I also throw away the memory of what I was doing.
The distinction matters because discarding the wrong context is expensive. If I reset in the middle of a refactoring I lose decisions that were already made; if I never compact, every subsequent message carries thousands of useless tokens along with it. /compact is the middle ground: it lightens the load without forcing me to start over.
⚙️ Auto-compaction: what happens when the context fills up
Claude Code does not wait for me to act. When context approaches its limit it manages the space on its own: first it discards the oldest tool outputs, then, if that is not enough, it summarises the conversation. My requests and key code snippets are preserved; detailed instructions given at the start may be lost.
The threshold is not fixed. Historically auto-compaction triggered around 95% fill, leaving just 25% of space remaining, but during 2025 the mechanism was made more conservative, in some cases firing earlier at 64–75% to avoid failed compactions. From early 2026 the operation also became instant, where before it would pause the session for a few seconds.
There is an edge case worth knowing: if a single file or output is so large that the context fills up again immediately after every summary, Claude Code stops trying to compact after a few attempts and surfaces an error instead of looping. When I see that, it is a signal that I am feeding too much material in one go: it is better to break the work into smaller pieces or filter the input.
- 01Context nearly fullClaude Code detects that available space is running out, with no action required from you.
- 02Old tool outputs discardedThe oldest tool outputs are removed first — the least useful things to keep.
- 03Conversation summarisedIf that is not enough, history is summarised: key requests and code snippets are retained.
- 04Session continuesThe session resumes with a lighter context, but detailed early instructions may have been lost.
Source: official Claude Code documentation (How Claude Code works, Manage costs).
🎯 /compact with focus: the instruction that changes everything
/compact on its own lets the assistant decide what to keep. But I can tell it myself by passing a focus: I write /compact Focus on code samples and API usage and the summary prioritises exactly that. It is the difference between a generic summary and one that retains what I need for the next steps.
When I want that rule to hold for the entire session I do not repeat it every time: I put it in the project's CLAUDE.md, in a Compact instructions section. There I write, for example, to concentrate on test output and code changes. From that point on every compaction — manual or automatic — follows that priority.
In practice I use the focus in three recurring situations, where I already know what matters and what is noise:
- Long refactoring: focus on design decisions and files already touched, so the assistant does not re-read everything from the top.
- Debugging: focus on test output and error messages — everything else can go.
- API integration: focus on endpoints, payloads, and response formats, which are what I reuse in subsequent steps.
⚖️ When to use /compact and when to use /clear
The question I ask before hitting enter is simple: am I continuing the same work, or starting something new? If it is the same, /compact. If I am switching topics entirely, /clear — because carrying over the context of a closed task just wastes tokens on every subsequent message.
One habit that makes a real difference is compacting while the cache is still warm. Prompt caching in Claude Code cuts the cost of repeated content, and a well-timed compaction preserves those savings. Before clearing with /clear I use /rename to keep the session findable and /resume to come back to it if needed.
/compact — same work
- Summarises the conversation and reloads it
- Keeps key requests and code snippets
- Maintains the thread of the current task
- Ideal mid-refactoring or mid-debug
/clear — new work
- Wipes the entire conversation history
- Restarts from an empty context
- Use when switching topics entirely
- Pair with /rename and /resume to find the session later
🗺️ The workflow I follow to never lose context
The rule I set for myself is never to exceed 60% context usage in a single session. Beyond that threshold quality drops and costs rise, because every extra token is re-read with every message. To see where I stand I use /context, which shows what is occupying space, and /usage for tokens consumed.
When I get close I compact proactively with a focus, rather than waiting for the automatic trigger to fire in the middle of a train of thought. Compacting when I decide — not when the context is at breaking point — is what keeps a long session sharp from start to finish.
The mini-playbook I follow, in order:
- Keep tasks small: a focused request consumes less context and produces better results than a mega-prompt.
- Check with /context as soon as the session gets long, to see what is actually taking up space.
- Compact with a focus around 60%, specifying what to keep.
- Use /clear between unrelated tasks, after a /rename so the session remains findable.
- Move stable instructions into CLAUDE.md, so they do not depend on history that will eventually be compacted away.
Frequently asked questions about /compact command Claude Code
Are /compact and /clear the same thing?
No, and confusing them wastes context. /compact summarises the conversation and reloads it, preserving key requests and code; /clear wipes everything and starts from zero. I use /compact when continuing the same work, /clear only when switching topics entirely.
Can I decide what Claude Code keeps during compaction?
Yes. I pass a focus to the command — for example /compact Focus on code samples and API usage — or I add a Compact instructions section to the project's CLAUDE.md. Either way I tell it explicitly what to keep, instead of leaving the choice to the automatic mechanism.
Why does auto-compaction sometimes fire at the wrong moment?
Because it triggers based on context fill, not on my workflow: historically around 95%, then moved earlier in some cases to avoid failed compactions. If I do not want surprises mid-reasoning I compact proactively, before things get critical, around 60% usage.
Does compacting actually help reduce costs?
Yes, because in Claude Code tokens grow with context size: the more history I carry, the more I pay with every message. Compacting at the right time, while prompt caching is still warm, keeps context small and spending under control, without forcing me to start over.
Let's talk
If this topic is relevant to you, write to me: comparing notes on code and AI is always time well spent.