The /compact command compresses your conversation history to free context space. It is the primary tool for extending long sessions past the point where context would otherwise fill up and degrade. But it comes with a catch: compact is lossy.
Before compact: src/auth/middleware.ts:45 → validateToken(). After compact: “the authentication module” and “a validation function.” The compression summarized away the specific details that matter most.
The solution is a three-step workflow: save findings to a scratchpad file, compact the conversation, restore findings by reading the scratchpad.
Why /compact Is Lossy
/compact reduces context by summarizing the conversation history. Summarization, by nature, replaces specifics with generalities. File paths become “the auth module.” Function signatures become “a validation function.” Line numbers disappear entirely. The compressed history preserves the narrative (“we explored authentication”) but drops the precision (“file X, line Y, function Z”).
This is not a bug. It is the inherent tradeoff of compression. The question is whether you prepare for it or get surprised by it.
The Three Steps
Step 1: Save
Before running /compact, write all critical findings to a scratchpad file:
Claude, write our current findings to findings.md:
- src/auth/middleware.ts:45 → validateToken() checks JWT expiry
- src/db/pool.ts:8 → connection pool max=20, timeout=5000ms
- Bug: src/api/orders.ts:112 — race condition on concurrent updates
- Architecture: auth middleware wraps all /api/* routesThis takes about 30 seconds. The information is now on disk, immune to any context operation.
Step 2: Compact
Run /compact. The conversation history compresses, freeing context space. Specific references in the conversation may be summarized away. That is expected — the scratchpad has them.
Step 3: Restore
After compact, read the scratchpad:
Read findings.md to restore our exploration context.The agent now has the critical specifics back in its working context, plus the freed space to continue exploring.
The Data: 30 Seconds That Save 8 Minutes
A controlled comparison across exploration sessions:
| Metric | Compact without scratchpad | Compact with scratchpad |
|---|---|---|
| Specific references lost | 40% | 3% |
| Rework (re-discovering info) | 25% of session | 2% of session |
| Average rework time per session | 8 minutes | ~0 |
| Pre-compact save time | 0 | 30 seconds |
The 30-second investment in saving to a scratchpad eliminates nearly all post-compact information loss. The 3% residual loss represents edge cases — findings not explicitly saved to the file.
Why “Just Re-Grep It” Does Not Work
A common objection: “If compact loses a file path, I can just Grep for it again.” This works for simple text patterns, but many exploration findings cannot be re-discovered with search:
- Architecture understanding — “the auth middleware wraps all /api/* routes and delegates to service-specific handlers” came from reading multiple files and reasoning about the flow, not from a single searchable string.
- Cross-file dependency mappings — knowing that module A depends on module B through an indirect import chain required tracing several Read operations.
- Bug analysis — “race condition on concurrent order updates because the read-check-write sequence is not atomic” was a conclusion from reading the code, not a string in any file.
Grep recovers strings. Scratchpad recovers understanding. The distinction matters when your findings came from reasoning over multiple files, not from matching patterns.
Multiple Compact Cycles in Long Sessions
Extended sessions (60+ minutes) often need 2-3 compact operations. A single scratchpad save-and-overwrite before each compact loses earlier findings. The correct approach: append incrementally.
The scratchpad file grows throughout the session:
- Cycle 1: Explore auth → save auth findings to scratchpad → compact → read scratchpad
- Cycle 2: Explore database → append DB findings to scratchpad → compact → read scratchpad
- Cycle 3: Explore API → append API findings to scratchpad → compact → read scratchpad
After cycle 3, the scratchpad contains findings from all three exploration phases. Each compact may have individually lost details, but the scratchpad on disk accumulated everything. Reading it after each compact restores the full picture.
Overwriting the scratchpad each time (instead of appending) discards earlier findings. Architecture decisions from the first exploration phase are just as critical during implementation as the latest discoveries.
When Compact Is Not the Right Tool
/compact addresses context fullness, not context complexity. Two situations where it is the wrong choice:
Scheduled compaction on a timer. One proposal: run /compact after every 10 tool calls, proactively. The problem: compact is lossy, and scheduled use throws away potentially valuable recent context before it is needed. Better approaches for proactive context management include using the Explore subagent for isolated discovery (the sub-agent’s context is separate, so the main context stays clean) or breaking work into scoped sub-tasks.
As a substitute for scratchpad persistence. Some developers run compact and hope for the best. At 40% reference loss per compact, running it 3 times in a session compounds the losses — critical early findings may be completely gone by the third cycle. Compact is a context management tool, not a persistence tool. Persistence is the scratchpad’s job.
Transitioning Between Work Phases
The save-compact-restore workflow is especially valuable at phase boundaries: transitioning from exploration to implementation, from interview mode to coding, from research to synthesis.
A developer using interview mode discovers 20+ requirements through questioning. Before transitioning to implementation, they write all requirements to a scratchpad file. If /compact is needed during the implementation phase (which is likely — implementation generates substantial context from file reads and edits), the requirements survive in the file. The implementation phase can read the scratchpad at any point to access the full requirement list, regardless of how many compacts have occurred.
Without the scratchpad, a single compact during implementation could reduce “validate email format with RFC 5322 regex, reject disposable domains” to “email validation.”
One-liner: Always write findings to a file before running /compact — compact frees space but loses details, and the scratchpad ensures nothing important disappears.