Skip to content
BSWEN
Blog

How to Manage and Compact Context in Claude Code When Conversations Get Too Long

Cowrie
Cowrie
Dev @ Bswen

Problem: Context Bloat During Long Sessions

I’ve been using Claude Code for extended coding sessions, and I kept running into the same issue: after a few hours of debugging, refactoring, and iterating, my conversations would get unwieldy. Claude would start forgetting things I mentioned earlier, or worse, I’d run into context limits.

Here’s what a typical messy debugging session looked like:

My conversation spiraling out of control
User: I need to fix the authentication bug


Claude: [reads 5 files, suggests fix]


User: That didn't work, here's the error


Claude: [reads 3 more files, suggests another fix]


User: Still broken, different error now


Claude: [more analysis, another suggestion]


... 20 more iterations of trial and error ...


User: Finally fixed! But wait, Claude seems confused about what the original requirement was...

I was burning through my token budget on failed attempts, and the important early context—project requirements, constraints, architectural decisions—was getting pushed out by all the debugging noise.

A Reddit user expressed the exact same concern: “Will using this with the pro plan use up my tokens really fast?” Another commented: “I’ve also been using /clear way more than I thought just to keep it from spiraling when I’m debugging something messy.”

The /clear command works, but it throws away everything—including the valuable context I built up. There had to be a better approach.

Solution: Surgical Context Compaction

I discovered that Claude Code offers two distinct approaches to context management, and the surgical approach is what most people miss.

Approach 1: The Nuclear Option - /clear

The /clear command is the blunt instrument:

Clearing all context
/clear

This completely resets your conversation. It’s useful when:

  • Starting a completely new task
  • Switching to a different project
  • Your context has become hopelessly confused

But there’s a major tradeoff: you lose everything. All the project understanding, all the successful patterns you established, all the architectural context—gone.

Approach 2: Surgical Compaction (The Better Way)

Here’s the feature most developers don’t know about. Claude Code has a surgical compaction feature that compresses trial-and-error sessions while preserving the important early context.

The steps:

  1. Double-tap the Esc key to open the rewind menu
  2. Navigate through your conversation history
  3. Select “Summarise from here” option
  4. Claude compresses everything from that point into a dense summary

Let me show you how this works in practice.

My workflow before compaction
[Messages 1-10]  Project setup, requirements, initial architecture decisions
[Messages 11-50] Debugging session with 15 failed attempts
[Messages 51-60] Breakthrough, solution found
[Messages 61-70] Additional cleanup and refinement

When I compact from message 10 to message 60:

After surgical compaction
[Messages 1-10]  Project setup, requirements, initial architecture decisions (preserved)
[Summary]        "Debugging session attempted 15 approaches: tried X (failed because Y),
                  tried Z (failed because W), finally succeeded with approach A which..."
[Messages 61-70] Additional cleanup and refinement (preserved)

The summary captures what I learned without the verbose back-and-forth. I keep the “why” while discarding the noise.

Why This Matters for Token Budget

I’m on a pro plan, so token efficiency matters. Here’s what I learned about the economics:

Without compaction:

  • Debugging session: ~40,000 tokens of trial-and-error
  • Context fills up
  • Claude starts forgetting early requirements
  • I run out of budget faster

With surgical compaction:

  • Same debugging session: ~40,000 tokens originally
  • After compaction: ~5,000 tokens (roughly 10-20% of original)
  • Early context preserved
  • Budget preserved for actual work

The compaction uses fractional tokens because summaries are dense. You reclaim 80-90% of the token cost while keeping the essential narrative.

Common Mistakes I Made

Mistake 1: Overusing /clear

Initially, I treated /clear as my only option. Every time context got messy, I’d clear and start over. But then I’d spend the first 10 minutes re-explaining the project to Claude.

What I was doing wrong
/debugging for 2 hours/
User: /clear
User: Okay, let me start over. I'm building a REST API with these requirements...
[Claude has no memory of the 2 hours of work just completed]

The fix: Use surgical compaction instead. Preserve the project setup, compact the debugging noise.

Mistake 2: Waiting Too Long to Compact

I used to wait until Claude started dropping context or giving confused responses. By then, the important early messages might already be pushed out of the window.

Now I compact proactively:

  • After a successful debugging breakthrough
  • Before starting a new phase of work
  • When I notice the conversation getting long
  • Before complex operations that will add significant context

Mistake 3: Compacting Everything Indiscriminately

My first attempt at compaction, I selected the wrong point and compacted my project requirements. Claude then had no idea what constraints we were working under.

The lesson: Be selective. Keep:

  • Initial requirements and constraints
  • Key architectural decisions
  • Successful implementations
  • Important “why” explanations

Compact:

  • Failed debugging attempts
  • Trial-and-error iterations
  • Exploratory searches that didn’t pan out
  • Redundant clarifications

Mistake 4: Not Using the Rewind Menu

I tried to remember which message number to compact from, which was error-prone. The rewind menu (double-tap Esc) lets me visually review the conversation and select the right compaction point.

Mistake 5: Ignoring the Token Budget Display

Claude Code shows token usage, but I used to ignore it until problems appeared. Now I check it periodically and compact strategically to stay within budget.

Best Practices I’ve Adopted

After learning these lessons, here’s my current approach:

1. Compact early, compact often

Don’t wait for problems. After any significant debugging session that resulted in a solution, I compact the failed attempts.

2. Use surgical compaction over /clear

/clear is for switching projects or truly hopeless contexts. Surgical compaction preserves too much valuable context to ignore.

3. Compact after breakthroughs

Once debugging succeeds, the failed attempts are no longer needed. Compact them immediately.

4. Compact before complex operations

If I’m about to do a large refactoring that will add significant context, I free up budget first.

5. Preserve initial project context

I always keep the first 10-20 messages that establish project requirements, constraints, and architecture. These are the foundation that everything else builds on.

The reason this matters goes back to how LLMs work.

Claude has a finite context window—roughly 200K tokens. Every message, every file read, every tool use consumes part of that window. When it fills up, the oldest messages are dropped automatically (FIFO—first in, first out).

This creates a problem for long sessions:

Context window lifecycle
[Start]                    [Middle]                    [End]
Requirements...            ...debugging...debugging...   ...debugging
                           ...debugging...debugging...   ...debugging
                           ...debugging...debugging...   ...debugging


If context fills, requirements get dropped first.
Claude forgets WHY we were debugging.

Surgical compaction solves this by converting verbose debugging into dense summaries, keeping the requirements while shrinking the middle:

After compaction
[Start]                    [Summary]                    [End]
Requirements...            ...summary of debugging...    ...refinement


Requirements stay in context.
Claude remembers the WHY.

How This Compares to Other Tools

Other AI coding assistants handle context differently:

  • GitHub Copilot: Limited to open files, no session history to manage
  • Cursor: Has compact mode but less granular control
  • Aider: Uses git context but can get confused with long sessions

Claude Code’s surgical compaction is unique in offering user-controlled, selective summarization.

Summary

In this post, I explored Claude Code’s two context management approaches: the /clear command for complete resets and the surgical compaction feature (double-tap Esc + “Summarise from here”) for selective compression. I covered why surgical compaction is superior—it preserves project narrative while reclaiming 80-90% of tokens from verbose debugging sessions.

The key insight is that context bloat is inevitable in long coding sessions, but losing valuable context isn’t. Start using compaction proactively after debugging breakthroughs and before complex operations. Your future self (and your token budget) will thank you.

Next time you’re in a messy debugging session, try the surgical compaction instead of clearing everything—you’ll keep the solution while discarding the failures that led you there.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: