What Claude Code compaction keeps, loses and cannot prove.

A Claude Code session has a context window, the working space holding conversation history, file contents, command output, instructions and tool definitions. As work continues, those items consume more of the window. A crowded context can leave less room for the next operation and contribute to the failure pattern I call the dumbzone.

Claude Code manages this pressure automatically, but no summary can retain every detail from a long exchange. The professional question is therefore not simply how to make the count fall. It is how to preserve the decisions, evidence and unfinished work that must survive when older conversation is shortened.

The commands solve different problems. Current Claude Code documentation describes /clear as starting a new conversation with empty context while leaving the previous conversation available through /resume. /compact continues the current conversation by replacing earlier history with a structured summary. It can accept a focus instruction, such as preserving the API changes.

Compaction is lossy. According to the current docs, Claude Code first clears older tool outputs and then summarises the conversation when more space is needed. Project-root instructions and auto memory are reloaded, while path-scoped rules and nested instruction files may not return until a matching file is read again. The exact summary is generated, so treat it as continuity assistance rather than a complete archive.

As of this update, Anthropic documents two environment variables. The first changes the capacity used for auto-compaction calculations; the second can request an earlier percentage threshold:

CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=92

These values show the original setup, not a recommendation for every session. The official environment-variable reference says the effective window cannot exceed the model's actual window, and that the percentage is applied to the configured capacity. It also warns that the status line's used percentage continues to use the model's full window, so the display and custom compaction threshold may not align.

Do not rely on an undocumented variable, an old default or an assumed reload rule. Check the current docs, start a controlled session, inspect it with /context and keep manual /compact available. The official repository also contains version-specific reports of auto-compaction not firing, so a configured threshold is not proof that the event occurred.

Suppose an agent is halfway through adding invitation expiry. Before a manual compact, it writes a checkpoint in the project:

Goal: reject invitations older than 24 hours.
Decision: use the server clock in UTC; do not delete expired rows.
Changed: invitation service and focused tests.
Evidence: expiry test red before change, now green; full suite not run.
Open risk: existing mobile client may depend on the old error code.
Next: inspect mobile usage, run the full suite, then request review.

Then run /compact preserve the invitation-expiry checkpoint and open risk. After compaction, reopen the checkpoint and relevant files, inspect the diff and rerun the focused test. If the summary says the full suite passed, the checkpoint exposes the contradiction. If the mobile-client dependency remains unclear, stop and investigate rather than allowing the shorter history to turn uncertainty into a decision.

Recovery rule: when continuity is doubtful, return to authoritative files, version-control state and executable evidence. A generated summary can help locate them, but it should not outrank them.

Compaction may fail when the request is already too large, and a very large file or tool output can refill the window after summarisation. Current error guidance recommends stepping back several messages and trying /compact again; if that cannot recover enough space, /clear starts fresh and /resume keeps the prior conversation available. Exact behaviour can still vary by release.

Keep stable rules in the documented instruction locations. Keep task state in a checkpoint that a person can inspect. Keep evidence in tests, logs and version control. Then let compaction do the narrower job it is designed for: making room to continue. As a student, I treat the summary as a useful hypothesis about the past. As a professional, I recover the work from sources that can still prove what happened.