Surviving the Dumb Zone: A Checkpoint System for Claude Code's /compact

In my previous post on the dumb zone, I covered how LLM reasoning quality degrades with absolute token count — not percentage fill — and how a statusline can tell you which zone you're in. The natural follow-up question: what do you do when you hit the dumb zone?

The default answer is /compact. Claude Code compresses your conversation into a summary, freeing the context window. You drop back toward the smart zone and keep working.

The problem: /compact is lossy in systematic, predictable ways. And the things it loses are the things that hurt worst when they're gone.

What /compact Actually Does

When you run /compact, Claude Code replaces your full conversation history with a compressed summary. The summary captures the general shape of what happened — the task, the approach, recent progress. The original messages, tool outputs, and reasoning chains are discarded.

This works well for the parts of a conversation that are narrative: "we decided to use approach X, implemented it in file Y, and it passes tests." Summaries handle narrative fine.

It fails for the parts that are structural:

1. Exact numeric details. IDs, line numbers, error codes, commit SHAs, threshold values. A dialogue-summarization study found models retained numerical keywords only 7.8–28.3% of the time¹.

2. Attempted-and-abandoned approaches. Summaries privilege the final story. The three approaches you tried and reverted — with the specific reasons each failed — get compressed to nothing. Post-compaction, the model retries the approach you already proved broken.

3. Governance and behavioral constraints. A 2026 paper found context compaction raises governance constraint violations from 0% to 30% pooled across models, up to 59% for some². A documented Claude Code bug showed /compact dropping CLAUDE.md safety rules, causing an unauthorized npx cdk deploy.

4. External state mutations. This is the dangerous one. If your session pushed a branch, created a PR, called an API, or started a deployment, that mutation happened outside the context window. Compaction can lose the record that it happened. Post-compaction, the model may repeat a non-idempotent operation because it no longer knows the first one succeeded.

The Failure Mode That Matters Most

The external state problem deserves its own section because it has the highest blast radius.

Consider a session that:

1. Implements a feature across three files
2. Runs tests (they pass)
3. Commits and pushes to a branch
4. Creates a PR with gh pr create

At this point, the session has consumed enough context to cross into the dumb zone. You run /compact. The summary captures "implemented feature X, tests pass, PR created." But does it capture the PR number? The branch name? The exact commit SHA?

Sometimes it does. Sometimes it doesn't. And "sometimes" is not a property you want in a system that controls whether a second PR gets created on top of the first.

The same problem applies at every external boundary: S3 uploads, database migrations, CI triggers, Slack messages, Jira transitions. Any operation where "did this already happen?" is not answerable from the local filesystem alone.

The Solution: Write Ground Truth Before Compaction

The fix is to not trust the summary. Write the facts to a file before compaction, then read them back afterward.

I built this as two Claude Code skills — /precompact and /postcompact — that bracket every /compact invocation.

Before /compact: Write the checkpoint

/precompact writes a structured checkpoint to .ai/compact-checkpoint.md. The file captures everything that compaction reliably loses:

# Compact Checkpoint

SESSION_ID: e63063fa-18e0-4a81-abac-4bb39eb04eae
MODEL: claude-opus-4-6[1m]
ROLE: implementation
CWD: /Users/me/projects/fleet-cli
TIMESTAMP: 2026-09-22T14:30:00Z
COMPACTION_COUNT: 1

---

## Goal
Build the fleet watch command — a read-only TUI status board
showing agent states from the fleet state file.

## Active Tasks
| # | Task | Status | Notes |
|---|------|--------|-------|
| 1 | Implement watch command scaffold | DONE | cmd/fleet/watch.go |
| 2 | Add TUI rendering with bubbletea | IN_PROGRESS | Basic table working |
| 3 | Connect to state file watcher | PENDING | |

## External State
| System | Identifier | Applied? | Idempotent? | Verify command |
|--------|-----------|----------|-------------|----------------|
| git branch | fleet-watch-spike | yes | yes | git branch --list fleet-watch-spike |
| git push | origin/fleet-watch-spike | yes | yes | git ls-remote origin fleet-watch-spike |

## Key Decisions
- **Q:** Use bubbletea or lipgloss for TUI?
  **D:** bubbletea — it handles input/update/view lifecycle.
  **Why:** lipgloss is styling-only, no event loop.

## Attempted and Abandoned
- **Approach:** Polled state file with fsnotify
  **Result:** Race condition on partial writes — 3/10 reads got truncated JSON
  **Do not retry:** fsnotify on the state file directly

## State File Pointers
- `.ai/plan/fleet-watch.md` — implementation plan

## Resume Instruction
Run `go test ./internal/watch/...` and fix any failures,
then implement the state file watcher using atomic read
(read into buffer, unmarshal, retry on error).

Every section exists because a specific failure mode demands it:

• External State prevents replaying non-idempotent mutations. The verify command lets the post-compaction session check before acting.
• Key Decisions prevents re-litigating settled questions. A degraded model loves to reopen decisions because it can't remember the reasoning that closed them.
• Attempted and Abandoned prevents retrying broken approaches. This is the single most common post-compaction failure I've seen: the model spends 5 minutes rediscovering that an approach doesn't work.
• Resume Instruction is a concrete next action, not "continue working." The post-compaction session reads this line and executes it.

After /compact: Cross-check and reconcile

/postcompact reads the checkpoint and uses it as ground truth. It does three things:

1. Cross-check the compacted summary. Compare what the summary retained against what the checkpoint recorded. The checkpoint wins every conflict. Pay special attention to:

• DONE tasks that the summary dropped (without them, the model redoes finished work)
• External mutations the summary forgot (the most dangerous gap)
• Decisions and their rationale (without them, the model re-opens settled questions)

2. Read state file pointers. The checkpoint lists files that carry operational context (.ai/plan/, .ai/status/, etc.). Read the headers of each. These files are on disk — they didn't get compacted. They're fresh context at disk-read cost, not summary-of-a-summary cost.

3. Reconcile external state against live systems. This is the step that prevents the worst failures. Before executing any resume instruction, verify that the checkpoint's External State section matches reality:

# Git: was the branch actually pushed?
git fetch --quiet origin
git branch -r --list 'origin/fleet-watch-spike'

# CI: did the last run pass?
gh run list --branch fleet-watch-spike --limit 3 --json status,conclusion

# PRs: does it exist?
gh pr list --state all --head fleet-watch-spike --json number,state

Each row in the External State table gets one of three outcomes:

• CONFIRMED: live state matches the checkpoint. Proceed.
• CORRECTED: live state differs. Update understanding to match reality. Log the correction.
• UNVERIFIABLE: the verify command failed or doesn't exist. Treat as UNKNOWN. If the operation is non-idempotent, stop and ask the user rather than risking a replay.

This reconciliation step catches a failure mode that no amount of checkpoint fidelity can prevent: things that happened during compaction. An agent might have pushed a commit while you were compacting. A CI run might have completed. The checkpoint was written before compaction; the world kept moving.

Why Not Just Hand Off to a Fresh Session?

This is the obvious alternative: instead of compacting, write a brief and spawn a fresh agent. I have a handoff skill that does exactly this — it writes a structured brief with an external state ledger, standing decisions, and remaining work, then launches a successor session. The question is when each approach wins.

Compaction wins when:

• The task is continuous within a single phase (you're still implementing, still debugging, still reviewing)
• State is externally verifiable (git, tests, CI)
• You don't need historical evidence from earlier in the conversation
• The human is present and can run /compact without disrupting their flow

Handoff wins when:

• You're crossing a semantic boundary (research to implementation, implementation to review)
• Non-idempotent external mutations have occurred that are hard to verify
• The model shows fidelity symptoms: repetition, forgotten constraints, circular reasoning
• The task type is changing entirely

The key insight from the research: the checkpoint system breaks the cumulative-drift chain. The standard argument against repeated compaction is that each round is a lossy summary of the previous lossy summary, and quality degrades monotonically. That argument assumes the summary is the only state carrier. When the checkpoint is written from full pre-compaction context and re-read from disk, each compaction cycle gets a fresh ground-truth injection. The 3rd compaction's checkpoint is no less accurate than the 1st's.

This means compaction with a checkpoint is safe to repeat within a coherent work phase. The handoff skill's original rule — "prefer handoff over compaction" — was written before the checkpoint system existed. With the checkpoint, the preference is weaker: compact within phases, hand off between phases.

The Research That Informed This

Three papers shaped the specific design choices:

Cross-Context Review (2025) tested whether a fresh session reviews code better than the same session. Fresh-session review achieved F1 of 28.6% versus 24.6% for same-session (p=0.008). Reviewing twice in the same session didn't beat reviewing once — the benefit comes from context separation, not repetition. This is why review sessions should always be separate from implementation sessions, regardless of compaction strategy.

Governance Decay (2026) measured how compaction affects constraint following. The finding — 0% to 30% constraint violation — is why the postcompact skill re-injects CLAUDE.md and behavioral rules as a distinct block rather than trusting the summary to preserve them.

Slipstream (2026) identified a fundamental problem with in-session validation of compaction quality: once a summary replaces original context, the agent's behavior is conditioned on the summary, so it can't independently detect its own compaction errors. The agent thinks everything is fine because it can't see what it lost. This is why the checkpoint must be written before compaction by the session that has full context, and the cross-check must compare against an external source of truth, not the agent's own recollection.

Practical Usage

The workflow in practice:

1. Work normally in the smart zone
2. Statusline shows WARN or DUMB → finish current subtask
3. Run /precompact → writes checkpoint to .ai/compact-checkpoint.md
4. Run /compact → Claude Code compresses the conversation
5. /postcompact runs automatically:
   - Reads checkpoint (ground truth)
   - Cross-checks against compacted summary
   - Reads state file pointers
   - Reconciles external state against live systems
   - Executes the resume instruction
6. Back in the smart zone with verified state

The checkpoint file is typically 50–100 lines. It points to other files rather than inlining their contents — the post-compaction session reads those files directly, getting fresh data at disk-read cost.

The total overhead is about 30 seconds per compaction cycle. The alternative — a post-compaction session that retries a broken approach, re-creates an existing PR, or re-pushes a branch — costs minutes to hours.

What This Doesn't Fix

The checkpoint system addresses state preservation across compaction. It does not fix reasoning degradation within a session. If the model is in the dumb zone and producing poor reasoning, compaction resets the context length but the summary quality depends on the degraded model that wrote it. The checkpoint provides external ground truth that the model can verify against, but it can't make a degraded model write a better summary.

For reasoning degradation specifically — the model showing circular logic, ignoring instructions, or producing incoherent plans — a fresh session via handoff is the right call. No amount of checkpointing saves a session that has lost the ability to reason about its own output.

The checkpoint system is a safety net, not a performance enhancer. It makes compaction safe where it was previously risky. The question of when to compact versus hand off remains a judgment call — but now it's a judgment call with a safety net underneath it.