How to Use the /compact Command in Claude Code to Prevent Context Rot
Running /compact at 60% context capacity—not 95%—keeps your Claude Code sessions sharp. Learn when and how to compact with specific preservation instructions.
Why Your Claude Code Sessions Drift (and How to Stop It)
Long Claude Code sessions have a predictable failure mode. You start sharp — clear context, accurate responses, tight reasoning. Then, somewhere around the two-hour mark, things get fuzzy. Claude starts forgetting earlier decisions. It re-asks questions you already answered. It suggests code that contradicts what it wrote an hour ago.
This is context rot, and it’s not a bug. It’s what happens when an AI’s working memory fills up and the oldest, most foundational information gets compressed or pushed out. The /compact command in Claude Code exists specifically to fight this — but most people use it wrong, waiting until the context window is nearly full instead of treating it as a proactive tool.
This guide covers what /compact actually does, when to run it for maximum effect, and how to write preservation instructions that keep your session coherent across compactions.
What Context Rot Actually Looks Like
Context rot shows up in subtle ways before it becomes obvious.
Early signs include Claude giving slightly inconsistent answers to the same question asked at different points in a session. It might reference a file structure that’s been reorganized, or suggest an approach you already ruled out thirty minutes ago.
Later-stage rot is harder to miss. Claude starts producing code that breaks established patterns. It loses track of the overall goal and optimizes for local problems instead. If you’re working on a multi-file refactor, it might forget which modules you’ve already touched or reintroduce changes you deliberately reverted.
The root cause is simple: every token in a conversation takes up space in the context window. Claude Code sessions accumulate fast — your prompts, Claude’s responses, file contents, tool call outputs, error messages, terminal output. By the time you’ve been coding for a couple of hours on anything non-trivial, you’re carrying a lot of noise alongside the signal.
When the context window approaches capacity, Claude’s underlying model has to work with an increasingly compressed view of your conversation history. Recent tokens stay sharp. Older ones get squeezed. The foundational context — the decisions made at the start of the session — is exactly what gets lost.
What /compact Does Under the Hood
The /compact command triggers a summarization of your current conversation history. Instead of keeping every token of every message, Claude replaces the full conversation with a condensed summary that preserves the most important information.
Think of it as controlled compression versus the chaotic compression that happens when you hit the context limit naturally. When you run /compact intentionally, you’re in charge of what gets preserved. When the context window fills up on its own, Claude’s model makes that call without your input — and it often gets it wrong, discarding architectural decisions and keeping mundane output that doesn’t matter.
After a compaction, Claude continues the session with the summarized context loaded. The conversation history visible in the UI gets replaced by a compact summary. New messages then build on that clean foundation.
The key word is intentional. Running /compact is a deliberate intervention. It’s you deciding to trade conversation fidelity for context quality. Done well, it makes Claude sharper. Done too late, it compresses details that were still actively useful.
The 60% Rule: Why Timing Matters More Than Most People Think
Most people run /compact when they notice problems — context warnings, degraded responses, or when Claude itself suggests it. By that point, you’re usually at 80–95% context capacity, and the damage is already partially done.
The better approach: compact at around 60% context utilization, before quality starts degrading.
Here’s why the threshold matters:
- At 60%, Claude still has full, uncompressed access to everything in your session. The summary it generates is based on complete information.
- At 80–95%, Claude is already working with partial or compressed context. Its summary of the conversation will reflect that degradation — you’re summarizing a degraded view, not the original.
Running /compact at 60% feels premature the first time you do it. You haven’t hit any errors. Everything seems fine. But that’s exactly the point — you’re locking in a high-quality summary while the context is still clean.
How to Track Context Utilization
Claude Code shows context utilization in the session interface. Look for the context indicator, usually displayed as a percentage or a bar. Different interfaces surface this differently, but it’s typically visible in the session header or status area.
Some developers set a personal rule: whenever context hits 60%, they stop what they’re doing and run /compact before continuing. This becomes habitual quickly and pays off in longer, more reliable sessions.
For very long sessions — multi-hour refactors, complex debugging marathons — you may need to compact multiple times. Each compaction resets the clock. Done right, you can run indefinitely without losing coherence.
Writing Preservation Instructions That Actually Work
The basic /compact command with no arguments will summarize your conversation automatically. This works, but it gives Claude full discretion over what to keep. For anything important, you want to be explicit.
You can append instructions directly to the command:
/compact Keep the following: current file structure with all modified paths, the decision to use PostgreSQL instead of SQLite and why, the three functions we identified as needing refactoring, and the current error in auth.ts that we haven't fixed yet.
That instruction set tells Claude exactly what to anchor the summary around. Everything else gets compressed more aggressively.
What to Include in Preservation Instructions
Good preservation instructions cover four categories:
1. Architectural decisions Any choice that would be hard to reconstruct from the code alone. “We decided to handle auth at the middleware level rather than in individual routes.” “We’re using optimistic UI updates for this feature.” These are easy to forget and expensive to re-litigate.
2. Active problems Bugs you’re mid-way through debugging. Errors you’ve identified but haven’t fixed. Pending questions. If you’re in the middle of tracking down a race condition, that context needs to survive the compaction.
3. File and scope context Which files have been modified. Which areas of the codebase are in scope. What you’ve explicitly decided to leave alone. This prevents Claude from re-suggesting changes to things you already handled or deliberately excluded.
4. Constraints and requirements Anything that limits your solution space. “Must stay compatible with Node 16.” “Can’t change the public API surface.” “The client requires that this works without a build step.” These constraints are easy to drop from a summary but critical to keep.
What to Leave Out
Don’t try to preserve everything — that defeats the purpose. Specifically avoid:
- Long error logs you’ve already resolved
- Exploratory tangents that didn’t pan out
- Verbose tool output that’s no longer relevant
- Early drafts of code that have since been replaced
The goal is a lean, accurate summary of where you are now and what matters going forward.
A Practical Compaction Workflow
Here’s a repeatable workflow for sessions where context management matters:
Before starting a session, write a brief session brief — two to five bullet points covering your goal, relevant constraints, and any decisions already made. Paste this at the start of the conversation. This gives you clean material to reference when writing preservation instructions later.
At 60% context, pause before compacting. Spend two minutes writing out what matters:
- What have we decided that isn’t obvious from the code?
- What are we currently stuck on or mid-way through?
- What constraints are still active?
- What files are in play?
Then run /compact with those notes as your preservation instruction.
After compacting, send a quick verification message: “Summarize where we are and what we’re working on next.” This confirms Claude’s post-compaction state matches your expectations. If something important got dropped, you can add it back immediately while it’s fresh.
Repeat at 60% of the new context window. After a compaction, you’re starting fresh — the next 60% threshold applies to the remaining capacity, not the original.
Common Mistakes and How to Avoid Them
Waiting for Warnings
Claude Code will warn you when context is nearly full. Treating that warning as your signal to compact means you’re already too late. The context has been degrading since well before the warning appeared. Use the warning as confirmation that your 60% rule is working, not as a trigger.
Compacting Without Instructions
Running /compact alone is better than not running it. But it’s leaving value on the table. Claude’s auto-summarization is decent but not tuned to your specific session. The decisions that matter most in your context are things Claude has no special reason to prioritize without guidance.
Over-specifying Preservation Instructions
The opposite problem: trying to preserve so much that the compaction doesn’t actually reduce context meaningfully. If your preservation instruction is three paragraphs long, you’re probably including things that don’t need explicit preservation. Aim for concise, high-signal instructions — five to ten items at most.
Forgetting Active Errors
This is the most common specific mistake. If you’re mid-debug when you compact, you need to explicitly tell Claude what the error is, what you’ve tried, and what you suspect. “We’re debugging a 500 error on POST /api/orders” gets compressed to nothing if you don’t flag it. After compaction, Claude may not even know there’s an open problem.
Not Verifying After Compaction
Always do a quick state-check after compacting. Ask Claude to confirm what it knows about the current state of the project. This takes thirty seconds and catches mismatches before they cause problems.
How MindStudio Fits Into Long-Running AI Workflows
Context management in Claude Code is fundamentally a problem of stateless AI sessions trying to handle stateful work. The /compact command is a good solution for in-session state, but it doesn’t help with the other half of the problem: what happens across sessions?
This is where MindStudio addresses something different but complementary. When you’re building AI-powered workflows that need to remember state across multiple sessions, users, or automation runs, you need infrastructure beyond a single agent’s context window.
MindStudio lets you build agents with persistent memory, structured inputs, and workflow state that survives between runs. If you’re running complex multi-step automation — not just a single Claude Code session, but a repeating process that spans days or involves multiple steps across different tools — MindStudio handles the orchestration layer that a single coding session can’t.
For example: if you’re using Claude Code to build a feature, and that feature is part of a larger automated workflow (say, an AI agent that processes customer data, generates reports, and posts updates to Slack on a schedule), MindStudio lets you build and manage that outer workflow without code. It connects to 1,000+ tools natively and supports Claude, GPT-4, Gemini, and other models — with no API key management required.
The Agent Skills Plugin is worth noting for developers specifically. It’s an npm SDK that lets any AI agent, including Claude Code agents, call MindStudio’s capabilities directly as typed method calls — things like agent.sendEmail(), agent.searchGoogle(), or agent.runWorkflow(). This means Claude Code can offload actions to a managed infrastructure layer instead of handling them inline, which reduces the token load on your context window.
You can try MindStudio free at mindstudio.ai.
Frequently Asked Questions
What does /compact do in Claude Code?
/compact summarizes the current conversation history to free up context window space. Instead of keeping a full verbatim record of every message, it replaces the history with a condensed version that preserves the key information. This lets you continue working without losing coherence as the session grows longer.
When should I run /compact in a Claude Code session?
The best time to run /compact is at around 60% context utilization — before quality starts degrading. Most people wait until they see context warnings or notice Claude getting confused, but by that point the context has already been partially compressed by the model. Compacting at 60% while the context is still clean produces a better summary.
Can I tell /compact what to keep?
Yes. You can append preservation instructions directly to the command. For example: /compact Keep: current file structure, the decision to use Redis for caching, and the unresolved error in middleware.ts. This tells Claude what to anchor the summary around. Without instructions, Claude decides on its own — which often deprioritizes decisions that aren’t explicit in the recent conversation.
Does /compact lose important information?
It can, if run carelessly or too late. The best way to protect against this is to write explicit preservation instructions covering architectural decisions, active problems, file context, and key constraints. After compacting, always verify by asking Claude to summarize the current state — this catches any dropped context immediately.
How many times can I compact in one session?
As many times as needed. Each compaction resets the context, so you can compact multiple times in a long session. The 60% rule applies after each compaction — watch for when context hits 60% of the new available window and compact again if you’re continuing.
Is there a difference between /compact and starting a new Claude Code session?
Yes. Starting a new session gives Claude a completely blank slate — no memory of your previous work unless you paste context in manually. /compact preserves a structured summary of your session, so Claude retains knowledge of decisions, progress, and constraints. For ongoing work, /compact is almost always better than starting fresh.
Key Takeaways
- Context rot is the gradual degradation of Claude Code session quality as the context window fills up. It’s a structural problem, not a random one.
- The
/compactcommand compresses conversation history into a summary. Run it proactively at 60% context utilization, not reactively when you see warnings. - Always include preservation instructions with
/compact— cover architectural decisions, active bugs, file scope, and active constraints. - After every compaction, send a quick verification message to confirm Claude’s state matches your expectations.
- For workflows that span multiple sessions or require persistent state across agents and tools, MindStudio handles the orchestration layer that in-session context management can’t address.
Good context hygiene is one of the highest-leverage habits you can build when working with Claude Code. The /compact command is simple — the skill is in using it early and deliberately.