Skip to content
BSWEN
Blog

When to Compact Claude Code Context vs Use the Full 1M Window?

Cowrie
Cowrie
Dev @ Bswen

I was in the middle of a complex refactoring task. Three files deep, tests passing, one more function to fix. Then Claude Code auto-compacted and lost all the context about why those variables were named that way, what the error patterns were, and how the pieces fit together.

I had to start over. Not from scratch, but close enough to be frustrating.

The 1M context window in Claude Code with Opus 4.6 sounds like it should solve this problem. But it doesn’t automatically—it just gives you more rope to hang yourself with if you don’t understand when to compact and when to preserve context.

The Real Problem

Here’s what most developers get wrong: they either let auto-compact trigger arbitrarily, or they assume 1M tokens means “never think about context again.”

Both approaches fail:

  1. Auto-compact at 80% (the default threshold) often triggers during critical implementation phases
  2. Never compacting leads to degraded model quality in the last 20% of the context window for complex reasoning tasks
  3. Compacting at wrong times loses exactly the context you need for the next step

I learned this through trial and error across dozens of sessions. Here’s what actually works.

When to Use the Full Window

Not all tasks benefit from aggressive context management. Some actively need the accumulated context:

Tasks that benefit from full context window
+------------------------+------------------------------------------+
| Task Type              | Why Full Context Helps                   |
+------------------------+------------------------------------------+
| Multi-file refactoring | Changes ripple across files              |
| Complex debugging      | Error patterns span multiple files       |
| Feature implementation | Need to maintain consistency              |
| Code review sessions   | Understanding intent across changes      |
| Architecture decisions | Seeing all connected components           |
+------------------------+------------------------------------------+

The key insight: these tasks have logical boundaries. A refactoring session has a “before exploration” and “after implementation.” A debugging session has “finding the error” and “fixing it.”

Compacting at those boundaries works. Compacting in the middle doesn’t.

When to Compact Strategically

I now manually trigger /compact at specific points, not when the tool decides:

Strategic compaction decision tree
                    Start Task
                        │
                        ▼
              ┌─────────────────┐
              │  Exploration    │──► COMPACT after done
              │  & Research      │    (keep findings, drop noise)
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │  Implementation │──► DON'T compact mid-work
              │  Phase          │    (preserve related changes)
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │  Debugging      │──► COMPACT after resolved
              │                 │    (remove error context)
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │  Milestone      │──► COMPACT
              │  Complete       │    (fresh window for next phase)
              └─────────────────┘

This approach ensures I never lose context during critical implementation phases, but also don’t let stale context accumulate.

My Configuration

I disabled auto-compact entirely and control it manually:

~/.claude/settings.json - Strategic compact control
{
  "autoCompact": false
}

For teams that want a safety net, there’s a custom threshold option:

Custom auto-compact threshold (optional)
# Triggers auto-compact at 300k tokens instead of 80% default
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=300000

The PreCompact Hook Pattern

If you do use auto-compact, the PreCompact hook is essential. It runs before compaction and can save critical state:

~/.claude/settings.json - PreCompact hook to preserve work
{
  "hooks": {
    "PreCompact": [{
      "hooks": [{
        "type": "prompt",
        "prompt": "Before compacting, save any critical in-progress work to task_plan.md. Preserve the current goal and any unresolved issues."
      }]
    }]
  }
}

This gives you a chance to persist important context to a file before it gets compacted away.

Why the Last 20% Matters

Here’s something I discovered empirically before finding it documented: the model’s reasoning quality degrades in the last 20% of the context window for complex tasks.

Context window quality zones
|<---------- Good Quality ----------->|<-- Degraded -->|
0%                                  80%              100%
                                     ▲
                                     │
                              Stop here for complex tasks

This isn’t about token costs. It’s about the model maintaining coherent reasoning. For large-scale refactoring or debugging complex interactions, staying below 80% keeps the model sharp.

Single-file edits, documentation updates, and simple bug fixes tolerate higher context usage. Know your task type.

The Workflow That Works

After many sessions of trial and error, here’s my standard workflow:

My context management workflow
1. Start task → Create plan file (externalizes key decisions)
2. Explore/search → COMPACT (keep plan, drop search noise)
3. Implement → Use full window, stay under 80%
4. Debug → Keep error context until resolved, then COMPACT
5. Milestone hit → COMPACT, start fresh for next phase

The plan file is crucial. It externalizes what matters, so when I compact, I don’t lose the “why” behind decisions.

Common Mistakes I Made

  1. Letting auto-compact trigger during debugging — Lost the error context I was actively using
  2. Compacting right before a major change — Had to re-read all the files I just compacted
  3. Assuming 1M meant infinite context — Model quality still degrades
  4. Not using plan files — Compacting loses decisions unless written down
  5. Ignoring the 80% quality threshold — Complex reasoning suffered in the last 20%

The Claude Code changelog (v1.0.45) shows the team’s thinking evolved here too:

  • Auto-compact threshold increased from 60% to 80%
  • PreCompact hooks added to allow state preservation
  • Context window blocking uses effective context window

These changes acknowledge that automatic compaction often interrupts at the wrong time.

Summary

In this post, I explained when to compact Claude Code context versus using the full 1M window. The key point is to compact at logical boundaries—after exploration, after debugging, after milestones—rather than letting auto-compact interrupt mid-task.

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: