The short answer
Compact at task boundaries, start fresh between tasks
The working rule, straight from Claude Code's own documentation: run /compact at a natural task boundary rather than letting an automatic compact interrupt you mid-task, use /clear between unrelated tasks, and if you have corrected the agent more than twice on the same issue, start a fresh session with a better prompt instead of compacting the confusion forward.
Behind that rule sits a mechanical truth this article unpacks: /compact is a lossy, model-written summary of your conversation, and both major vendors now say so in their own materials. Codex's source code warns that multiple compactions can reduce accuracy and recommends small, targeted new threads. Anthropic's engineering write-up on long-running agents reports that compaction alone was not enough, and that its harness moved to fresh-context resets with structured handoff artifacts.
So the choice has two immediate controls, compact or clear, plus a complementary practice that changes how safe both become: move the state that matters out of the context entirely, into files and notes that survive either.
The mechanics
What /compact actually does in Claude Code
When you run /compact, Claude Code makes a separate summarization request with your conversation and replaces the earlier turns with the resulting structured summary. You can steer it: /compact focus on the authentication changes is a documented form. Auto-compact does the same thing on a configurable window, adjustable from 100k to 1M tokens via /autocompact, the --autocompact launch flag, settings, or the CLAUDE_CODE_AUTO_COMPACT_WINDOW variable; left alone, it normally waits until the model's limit approaches.
Compaction does not flatten everything. Claude Code's documentation lists what is preserved or reintroduced afterward: the system prompt and output style, the root CLAUDE.md and applicable rules, auto-memory, the active plan, up to five previously read or edited files chosen by most-recent modification, with files over 5,000 tokens returning as path references rather than full contents, invoked skill bodies capped at 5,000 tokens each and 25,000 in total, and the status of background commands and subagents. Older tool output is cleared before the summary is even written.
Two costs are easy to miss. First, everything not on that preserved list survives only as whatever the summary chose to say about it. Second, compaction invalidates the conversation-prefix cache, so the turns after a compact repay the cache warmup that the long session had already earned.
The commands around it complete the picture: /clear (aliases /new and /reset) starts an empty conversation while leaving the old session resumable, claude --continue reopens the latest session in the directory, and claude --resume opens a picker. Clearing removes the prior conversation from the active context; the stored session stays resumable.
The evidence
What summarization measurably loses
None of the studies below repeatedly invokes the production /compact of Claude Code or Codex to measure fact retention per generation, so treat exact loss rates as unknown. The adjacent evidence, though, points one way.
- Write-time loss led in most tested systems. A 2026 preprint (WhenLoss, arXiv:2605.24579) tested memory systems on 500 LongMemEval questions across GPT-5.2, Claude Sonnet 4, and Gemini 2.5 Pro, and found four of six baselines limited primarily by information discarded when memory was written, a step analogous to compaction's summary writing, though the study did not test production /compact.
- Long noisy contexts underperformed short focused ones. Chroma's Context Rot study, spanning 194,480 calls across 18 models, found on a 306-question LongMemEval subset that every tested model answered better with roughly 300 focused tokens than with about 113,000 tokens of full history. Carrying everything is not the alternative to compacting; carrying the right little is.
- Vendor materials point the same way, with different weight. Codex's compaction source warns that multiple compactions can reduce accuracy; Anthropic's long-running-agent report, separately, describes compaction alone proving insufficient and its harness adopting fresh contexts plus structured handoff artifacts. On Linux.do, one poster's report of Codex mixing old and new experimental results after several compactions says the same thing anecdotally.
Across harnesses
Same goal, different machinery
If you run more than one harness, do not assume the compaction command means the same thing twice. The verified behavior, one line each:
| Harness | Compaction behavior, per its own docs or source |
|---|---|
| Claude Code | /compact with optional instructions; auto window configurable 100k to 1M tokens; documented preserved-state list |
| Codex | /compact plus configurable auto-compact; current source derives a default clamped at roughly 90% of the model window, an implementation detail rather than a contract; the rebuilt history retains up to about 20,000 tokens of prior user-message text alongside the compaction summary; source warns multiple compactions can reduce accuracy |
| OpenCode | /compact writes a lossy checkpoint but retains older messages in storage; auto-compaction on by default with a 20k buffer; current v1.18.31 source keeps 8k recent tokens by default while the live docs still state 15k |
| Pi | Auto-compaction on by default, 16,384 reserve and 20,000 recent tokens; tool results truncated to 2,000 characters before summarization |
| Oh My Pi | Opt-in experimental context management: a context_notes notebook, a new_context tool, and the full prior history retrievable via read and grep, instead of summary-of-summary |
| Qwen Code | /compress uses an LLM summary; /compress-fast removes old tool, media, and thinking content by rule, no API call, and saves a JSONL checkpoint; the automatic threshold has a 0.85 ceiling |
| Gemini CLI | /compress replaces chat context with a high-level summary (/compact is an alias); file-state checkpointing with /restore is a separate mechanism |
| Hermes Agent | Persistent MEMORY.md and USER.md plus session_search sit alongside compaction; optional rolling micro-compaction is off by default |
The spread matters because similar workflows meet different retention behavior in different harnesses: Pi truncates tool results to 2,000 characters before summarizing, OpenCode retains older messages in storage behind its checkpoint, and Qwen Code's /compress-fast removes old tool output without spending a single API call.
The third option
An emerging alternative to recursive summaries: externalize the state
Community discussions and several shipped experiments point at a related pattern: stop asking the model to remember, and move the state somewhere durable. Keep the raw transcript as the source of truth, roll into a fresh context at phase boundaries, and carry forward a small set of deliberately maintained notes rather than a summary of a summary. In late August and early September 2026, Chinese-language Linux.do threads about Codex worked through exactly this tension: one poster reported stale results surviving compaction, commenters proposed searchable transcripts and handoff documents instead, and a later source-reading thread described Codex's new experimental mode approximately as: continue in a fresh window, no summary generated.
It is concrete, with caveats, in at least three places. Codex 0.153.0 shipped eligibility-gated, off-by-default experimental context management: structured history notes, searchable stored history, and a new_context tool. Oh My Pi v18.1.16 keeps an opt-in, branch-local context_notes notebook and exposes the full prior history at history://current/full to read and grep, while stating that long-session quality is not yet established. Hermes maintains persistent MEMORY.md and USER.md files with session_search. Not everyone is convinced: Pi's upstream closed a fresh-context extension request as not planned. And the low-tech version needs no feature at all: write a handoff file, run /clear, and have the fresh session read it.
The design direction is consistent with the adjacent evidence, though none of these implementations has been validated against production /compact directly: decisions and constraints belong in durable, deliberately maintained artifacts, not in prose a model produced about prose a model produced.
The decision
Which tool, when
| Situation | What to do |
|---|---|
| Mid-task, context filling up, one continuous thread | Compact, at a boundary you choose, with an instruction naming what to keep: /compact focus on the schema migration. Do not wait for the automatic one to fire mid-thought. |
| Switching to an unrelated task | New session (/clear). The old session stays resumable; carrying its context into unrelated work only adds interference, which the long-context evidence prices in. |
| The agent has been corrected twice on the same thing | New session with a better opening prompt, per Claude Code's own guidance. Compacting a confused conversation summarizes the confusion. |
| Long-running work with decisions worth keeping | Externalize before you compress: write decisions, constraints, and current state to a file the next context reads, via a handoff document, history notes, or memory files, then compact or clear freely. |
Where HarnessRouter fits
Continuity that does not live in one window
The approaches above manage compression and handoffs inside individual harness workflows. When agents run behind a product, continuity has to survive across runs, machines, and even harnesses, which is why HarnessRouter keeps it in durable sessions, files, and artifacts rather than in any one context window: a task can continue its session later, and its outputs live in files and artifacts that no summary can drop. Each harness keeps its own native compaction behavior inside the run.
The cross-harness table above is also a benchmarkable claim: a sufficiently long task can hit context pressure very differently across harnesses. HarnessRouter runs them behind one API, so you can measure that on your own workload instead of assuming.
FAQ
Frequently asked questions
What is the difference between /compact and /clear in Claude Code?
/compact replaces the conversation so far with a model-written structured summary and keeps going, preserving a documented set of state such as CLAUDE.md, auto-memory, the active plan, and paths for recent large files. /clear (aliases /new and /reset) starts an empty conversation context, with persistent project configuration still loading as usual; the old session remains resumable with claude --continue or claude --resume.
When should I compact instead of starting a new session?
Compact when the work is one continuous thread and you are approaching the context limit; do it at a boundary you choose and pass an instruction naming what matters. Start a new session between unrelated tasks, or after the agent has been corrected more than twice on the same issue, which is Claude Code's own documented guidance.
Does Claude Code auto-compact lose information?
Compaction is lossy by design: everything outside the documented preserved list survives only as whatever the summary says about it, and older tool output is cleared before the summary is written. The available studies do not measure the production /compact's exact retention, but adjacent research found memory systems limited mainly by write-time information loss, Codex's source warns that multiple compactions can reduce accuracy, and Anthropic's long-running-agent write-up separately reports compaction alone proving insufficient for its harness.
Can I control what /compact keeps?
Yes. /compact accepts instructions, for example /compact focus on the authentication changes, and the auto-compact window is configurable from 100k to 1M tokens via /autocompact, the --autocompact launch flag, settings, or the CLAUDE_CODE_AUTO_COMPACT_WINDOW environment variable. For state you cannot afford to lose, write it to a file before compacting; files survive regardless of what the summary keeps.
Does Codex have a /compact command?
Yes. Codex documents /compact, which replaces earlier visible turns with a concise summary after confirmation, plus a configurable auto-compact token limit. Its own source warns that multiple compactions can reduce accuracy and recommends small targeted new threads, and Codex 0.153.0 added an opt-in experimental mode with history notes, searchable history, and a new_context tool. On the API side, OpenAI's Responses API offers a stateless /responses/compact endpoint and automatic server-side compaction via context_management.
Give long-running work a durable home
Run tasks whose sessions, files, and artifacts persist across runs, on the harness that performs best on your workload.
Start building free