Compaction in CC, Codex, and Opencode | Lexifina<br>FeaturesSecurityPricingBlogChangelogSign in
Blog/Research/Compaction
Blog/Research/Compaction
Compaction in CC, Codex, and Opencode<br>Alan Yahya·June 26, 2026·3 min read
Compacting context allows agents to keep working for a long time without suffering from context rot.<br>The premise is simple: for the current task, keep what matters, remove what does not (but index it so it can be looked up later), and give the model a clean view to continue working.<br>Claude Code, Codex, and Opencode all take a different approach to this.<br>What Compaction Needs To Do<br>A good compaction system has to do five things:<br>Notice when context is exceeding operational parameters for the given model.<br>Pick a clear boundary.<br>Replace expensive but recoverable data, like logs, file reads and tool output with a lookup artifact.<br>Preserve what the agent still needs: goals, decisions, open questions, and relevant files.<br>Apply the result to the runtime<br>The compaction that the agent uses is not about creating a nice coherent summary. It’s about creating a usable continuation state, optimised for an LLM.<br>Claude Code<br>CC treats compaction as part of building the next model request. Before it asks the model to summarize anything, it tries cheaper moves first: trimming large tool outputs, replacing heavy data with references, reusing compact boundaries, and projecting a smaller view of history. CC actively tries to avoid summarising data where possible using a mechanical approach. The saves on tokens. But the tradeoff is complexity. Because CC keeps trying cheaper pre-call reductions, the next prompt can be shaped by a stack of reducers, reused boundaries, and compacted views. That makes it efficient, but harder to tell exactly which reducer changed what the model sees.<br>Codex<br>Codex treats compaction as a hard state change. Before compaction, the session has one active history. After compaction, it has a new one. This makes the runtime easier to reason about. Compaction has a trigger, produces a new state, records the transition, and future turns continue from that new state. The strength of this is in the lifecycle. This state transition lends itself to telemetry and optimisation. The risk is that too much weight can land on the summary step. If big recoverable payloads are still included in the compact request, Codex may summarize things that could have been reduced first.<br>Opencode<br>Opencode's current design is basically a summary plus a tail, but the tail is not arbitrary. It is selected against the remaining budget and turn boundaries, so the recent slice passed forward is exact and coherent. Nor does Opencode really replace the session history with a separate compacted artifact. The transcript remains the source of truth, and each model call is rebuilt as a projection of that state: the compaction request, a summary assistant message, the exact retained tail, and any newer messages. This works well because older history gets compressed while recent details stay precise. Opencode also does some cheap cleanup around compaction: it strips media, caps large tool outputs, skips old completed compactions, anchors the previous summary, and replaces compacted tool results with lightweight placeholders.<br>In Summary<br>CC emphasises avoiding unnecessary summaries.<br>Codex emphasises making compaction explicit and durable.<br>Opencode takes a middle path.
Previous<br>Next