Claude Code auto-compacting token waste

Where the “waste” intuition comes from

You start a long session. You feed it a file tree, a system prompt, a set of decisions about how the codebase is laid out, a few hours of edits, the output of a long-running test run. The model is sharp. Then around the 60th turn you ask a follow-up that references a specific variable from turn 8, and the model confidently invents a different name. You stop. You retype the actual name. You notice the status bar says compacting a few turns back. You feel like you paid for context you do not have anymore. That is the moment people call this token waste.

The instinct is right that something got thrown away. It is the location that is wrong. The original turns are still on disk in ~/.claude/projects. The summary that replaced them is in the model's live window. The dollars you paid for the original turns are gone, not because the summary cost a lot, but because the model no longer benefits from them. Your hourly budget pays the difference in retyping.

What the SDK actually emits at the boundary

The compaction is not silent at the protocol layer, only in most UIs. The Claude Code SDK fires a system event with subtype compact_boundary at the moment the decision is made, then opens a content block of type compaction and streams compaction_delta chunks until the summary is done. In the open-source Fazm ACP bridge you can see the forward path in full:

// acp-bridge/src/patched-acp-entry.mjs (lines 99-107)
if (subtype === "compact_boundary") {
  await acpClient.sessionUpdate({
    sessionId: sid,
    update: {
      sessionUpdate: "compact_boundary",
      trigger: item.value.compact_metadata?.trigger ?? "auto",
      preTokens: item.value.compact_metadata?.pre_tokens ?? 0,
    },
  });
}

The trigger is either auto (the SDK decided) or manual (you typed /compact). pre_tokens is the integer that tells you exactly how much live context the summarizer is about to flatten. A boundary firing with pre_tokens near the model's context window means the summarizer is squeezing close to that whole budget into a paragraph, with everything that implies for what survives.

Why the standard advice is the same lever in three coats

Look at what the well-meaning playbooks tell you to do when long Claude Code sessions misbehave. Run /clear earlier. Run /compact on purpose. Set --max-turns low. Drop to Sonnet on the cheap turns. All of these reduce context. None of them keep the part of the context the next turn will actually need. They are versions of one move: shrink the input. The SDK has a different primitive that nobody surfaces: session/fork.

What forking looks like at the bridge layer

The fork primitive lives in @agentclientprotocol/claude-agent-acp as the experimental unstable_forkSession RPC. The bridge wraps it in a normal request that takes the parent sessionId, returns a fresh one rooted at the end of the parent's history, and registers the new session under a new (or in-place) key. From acp-bridge/src/index.ts around line 3862:

// acp-bridge/src/index.ts (lines 3862-3866)
const result = await acpRequest("session/fork", {
  sessionId: sourceEntry.sessionId,
  cwd,
  mcpServers: buildMcpServers(mode, cwd, msg.toSessionKey),
}) as { sessionId: string };

The result is an honest new session. The parent's JSONL is unchanged. The new session can take a different model, a different mode, or no changes at all. Crucially the new session starts with the parent's conversation as the SDK actually had it, not as the summarizer rewrote it. This is the move you want when you can feel the boundary coming and you have not yet lost the specifics.

A working pattern that does not depend on Fazm

If you are running raw Claude Code, you can get most of this with the CLI you already have. Watch the status bar for compacting or check the JSONL for compact_boundary entries with jq. When you see one fire near the window limit, stop the session, copy the last few of your own messages and the load-bearing tool results into a fresh prompt, and start a new conversation with that as the preamble. It is the manual version of fork. It is annoying, but it gives the new session the original bytes the model needs, not the paragraph the summarizer wrote.

# Find every auto-compact boundary in a Claude Code session
SESSION=~/.claude/projects/-Users-you-proj/<session>.jsonl
jq -r 'select(.type=="system" and .subtype=="compact_boundary")
       | "\(.compact_metadata.trigger) \(.compact_metadata.pre_tokens)"' \
   "$SESSION"

The values you get back are the same trigger and pre_tokens the SDK emitted live. They are your record of how much context the model lost and when. A host that surfaces this in real time saves you the post-mortem with jq.

What this changes about how you run long sessions

The mental model worth holding is that auto-compact is a soft failure mode of context being too large for the model, not a feature that saves you money. The summary is cheap. The lost specificity is not. Once you stop optimising the summary itself and start treating the boundary as a fork point, two things change. You stop running one long session and start running a small chain of shorter ones, each forked from the previous at a clean moment. You also stop retyping facts the model already knew, because the next session in the chain starts with those facts in the input rather than in a paragraph about them. The savings show up as fewer retypes, fewer hallucinations, and fewer rerolls on the same prompt, not as a smaller line on the invoice.