Docs / Field guide / When to fork, compact, auto-compact or clear

When to fork, compact, auto-compact or clear

A long agent session is like a workbench. Clearing sweeps it bare. Compacting packs the clutter into a labelled box and keeps working. Forking sets up a second bench with a copy of everything on the first. Each has its moment, and each costs something different.

You want toClaude CodeCodexCosts
Start unrelated work/clear/new, or /clear to wipe the screen toonothing carried over; the next turn starts small
Keep going on the same task with less history/compact, optionally with a focus/compactone summary turn, then a cold cache for the new, shorter history
Let the engine decideautomatic near the limit; /autocompact sets the thresholdmodel_auto_compact_token_limit in config.tomlthe same, at a moment you didn't choose
Try an alternative without losing this line/branch switches you into a copy; /fork runs the copy in the background; /subtask hands a forked helper one job/forkcheap: the copy shares the cached history
Undo a path you went down/rewindno direct equivalent: /fork before the risky step insteadcheap in Claude Code: it falls back to history that is already cached

Clear#

Clear between unrelated jobs. Old conversation crowds out the files the next job needs and is paid for again on every turn. Anything worth keeping should already be in a file: the instruction file, a record, a commit message.

Compact#

Compact at a natural break inside one job, such as after a feature works and before its tests. Add a focus so the summary keeps what matters: /compact keep the auth decisions and the failing test names. Done while the cache is warm, it is cheap. Done after a long break, the summary has to read the whole history uncached first.

Auto-compact#

Auto-compaction keeps a session alive, but it happens mid-thought and guesses what to keep. In Claude Code the project's root CLAUDE.md and auto memory are re-read afterwards and a few recent files come back. Rules that only loaded for one folder, and anything said only in chat, are summarised away. If something must survive compaction, write it to a file.

Fork#

Fork when the next step needs everything the session knows: a second approach to the same bug, or a risky experiment you might throw away. A fork inherits the conversation, so its first turn reads the cache the original built. A fresh agent starts cold and knows nothing, which is right for a different reason: a big search whose results you don't want in your own context.

A rule of thumb that has served us well: fork or reuse a warm agent by default, and start a fresh one only for size, for parallel work on separate files, or for isolation.

Where ADE fits#

ADE makes clearing cheap. Each card is small enough to finish in one window, its state lives in records rather than in chat, and the same generated handover arrives at session start and after compaction. So a cleared, compacted or forked session picks up the same picture. See handovers without recency bias.