// blog / workflow
/clear or /compact? A token decision tree
Ten listicles will tell you what the commands do. The useful question is which one, when — and when the answer is neither.
The decision tree
Is the NEXT thing you'll do related to what's in this session?
├── NO (different task, different files)
│ → /clear · old context is pure attention tax on the new task
│
├── YES, but the current phase is DONE (explored → now implementing;
│ implemented → now writing tests)
│ → /compact · keep decisions, drop the transcript that produced them
│
└── YES, and the model has failed the same fix TWICE
→ neither: restart, and put what you learned INTO the promptThe distinction underneath: /clear answers a topic change, /compact answers a phasechange. Compacting a session that should have been cleared keeps a summary of things the new task never needed; clearing a session that should have been compacted throws away decisions you'll re-derive at full token price.
The timing rule: compact at breakpoints, not at the limit
Compaction is itself lossy — a summary of a conversation is not the conversation. Run it at a natural breakpoint (phase done, tests green) while the session is still coherent, rather than waiting for the auto-compact at the window's edge, where degradation has already set in and the summary inherits the confusion. Same logic as committing before a risky refactor: snapshot at the good state.
The restart branch is the one that compounds
The third branch comes straight from Anthropic's Claude Code guidance: after two failed corrections, a clean session with a better prompt beats pushing the long session further. The corrections you typed were context engineering by hand — restating constraints the prompt should have carried. Fold them into the prompt, restart, and the failure becomes permanent progress. That fold-and-restart move is exactly why our own debugging and review prompts are versioned: session #2's corrections become v2 of root-cause-analysis, and session #3 starts sharper than #1 ever was.
One CLAUDE.md caveat while you're here: don't edit it mid-session to fix a misbehaving run — beyond the churn, prefix changes invalidate prompt caching and force an expensive cache re-write before the savings resume. Rules changes belong at session boundaries.