How I Manage Claude Code Compaction So It Helps Instead of Hurts

If you have spent any serious time in Claude Code, you have probably hit this wall: the session starts sharp, then gradually gets a little fuzzy, and eventually Claude is confidently doing something you explicitly told it not to do two hours ago. The culprit is usually compaction, and more specifically, the way most people let it run on autopilot.

Compaction itself is not the problem. It is a necessary mechanism for managing the context window. The problem is that the default behavior is both too late and too lossy. By the time auto-compaction kicks in, you have already stuffed a lot of nuanced decisions, constraints, and clarifications into the session. The compaction summary that gets generated captures the broad strokes, but the specifics, the "and whatever you do, don't touch the auth module" moments, often don't make it through. Run that process four or five times and you are essentially working with a Claude that has the vibe of your project but not the details.

Here is the system I use to fix that.

Step 1: Check What Loads Automatically Before You Do Anything Else

Before you write a single prompt in a new session, run /context and look at what is already consuming your context window. Claude Code can load project files, memory files, and other configuration automatically at startup, and some of those items are surprisingly expensive.

If anything is eating more than roughly 5% of your total context right out of the gate, ask yourself whether it actually needs to be there. Trim or relocate anything that does not need to be present for every session. This one habit gives you a meaningfully larger working budget before the conversation even begins, and it delays the point where compaction becomes relevant at all.

Step 2: Trigger Compaction Earlier Than the Default

The default compaction threshold is set high, usually somewhere around 70-80% of the context window. By that point, there is already a lot to lose. I change this setting so auto-compact fires at around 60% remaining context (roughly 40% used). This keeps each compaction event smaller and more manageable. The summaries are more accurate when there is less to summarize, and you lose less in the process.

You can adjust this in your Claude Code settings. It is a small change that makes a noticeable difference in session quality over time.

Step 3: Run a Summary Task Automatically Before Compaction Fires

This is the most important piece of the system. Add an auto task that runs just before compaction and does the following:

• Summarizes every significant decision made in the session so far
• Lists any explicit constraints or instructions you have given
• Notes the current state of whatever you are building

That summary should be written somewhere persistent. I drop mine into a dedicated note (a simple markdown file works fine). The key thing to manage here is that these summaries will pile up if you are not deliberate about it. I keep them for a specified length of time (like 14 days) and have Claude remove the previous summaries after that.

The goal is a crisp, human-readable record of everything that matters from the session so far. Think of it as the briefing document a new team member would need to get up to speed instantly.

Step 4: Paste the Summary Back In After Compaction

Compaction runs, context gets trimmed, and then the session continues. At this point, Claude is working from its own generated summary, which, as we established, is lossy. The fix is straightforward: after compaction completes, have Claude paste your pre-compaction summary back into the session.

This can be automated as a follow-on task in the same auto task setup. The sequence looks like this:

1. Pre-compaction task fires, generates and saves the summary
2. Compaction runs
3. Post-compaction task fires, reads the saved summary and injects it back into the context

Now Claude has both its own compaction summary and your richer, more detailed version. The session can continue without losing the specifics that actually drive quality output.

Step 5: Track Compaction Count in Your Status Line

Even with all of the above in place, compaction is still a lossy process. Each pass through it costs you something small. Stack four or five compactions in a single session and the cumulative loss starts to show up in Claude's behavior. It is not dramatic, it is subtle, but it is real.

The fix here is awareness. Add a compaction counter to your status line so you can see at a glance how many times compaction has fired in the current session. When that number creeps past four or five, it is a signal to wrap up what you are doing and start a fresh session for the next logical chunk of work.

This also encourages better session hygiene in general. Rather than running one enormous session that tries to do everything, you end up working in focused bursts with clear handoffs between them. That maps well to how complex projects actually need to be broken down anyway.

Putting It All Together

To recap the full system:

• Run /context at the start of every session and trim anything taking more than ~5% of context automatically
• Lower your auto-compact threshold to around 60% remaining context
• Set up a pre-compaction auto task that saves a detailed session summary to a managed note file and add management to clear them after a period of time
• Set up a post-compaction auto task that injects the saved summary back into the session
• Add a compaction counter to your status line and start a new session after 4-5 compactions

None of these steps are complicated individually. What makes them powerful is running them together as a consistent system. The difference in session quality, especially on longer, more complex projects, is significant.

Claude Code is a genuinely capable tool. The default compaction behavior just does not reflect how people actually use it for real work. These adjustments put you back in control of your context window instead of just hoping the auto-summary captures what matters.

If you want help setting up this kind of workflow for your team, or you are curious how to build other systems that make AI coding tools more reliable in practice, reach out to us at Thought Spark AI. This is exactly the kind of practical, implementation-level work we do with clients every day.