Model: openai/gpt-5.4 Generated: 2026-04-01 Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead Chapter: 5 — Session and Context Management Token Usage: Approx. 1,560 output tokens for this section

5.3 Context Compaction

Every long-running coding agent eventually collides with the same physical limit: the context window is finite, but real engineering work is not. A difficult bug hunt, a multi-file refactor, or a day-long autonomous run can easily produce far more tokens than a model can safely carry forward. Context compaction is the family of strategies used to survive that limit without losing the thread of work.

The background problem: context rot

The overflow problem is not only about hard token ceilings. It is also about quality degradation before the ceiling is reached. As context grows, retrieval inside the model becomes less reliable. Attention computation in transformers scales roughly with sequence length, often described in simplified form as quadratic, or O(n²), with respect to token count. Even when the model technically accepts a large prompt, the practical quality of recall, prioritization, and grounding can decline. This deterioration is often informally called context rot: the conversation still fits, but the agent remembers less clearly and reasons less sharply.

So compaction serves two purposes:

1. avoid hard overflow errors,
2. restore cognitive sharpness by reducing stale or noisy context.

OpenCode: summarize, mark, and continue

OpenCode’s compaction logic lives in session/compaction.ts. Its design is comparatively direct and elegant. The system estimates overflow by comparing token usage against the model’s usable input window after reserving room for output. If auto-compaction is enabled and the threshold is reached, OpenCode can summarize the session and continue.

The summary prompt in compaction.ts is revealing. It asks for a continuation-oriented summary with sections such as goal, instructions, discoveries, accomplished work, and relevant files. That is a strong signal that OpenCode views compaction not as compression in the abstract, but as a handoff from one working memory state to the next.

OpenCode also includes a lighter-weight mechanism: pruning old tool outputs. The prune function walks backward through earlier parts and clears completed tool outputs once enough token mass has accumulated, while protecting certain tools. This is important because tool output is often high-volume and low-value after its immediate use. Clearing old tool results is the mildest possible compaction: the message graph remains mostly intact, but bulky observations are trimmed.

So OpenCode effectively has two levels:

• light compaction: prune old tool results,
• hard compaction: summarize the conversation and reset the active context.

Claude Code: a five-layer defense system

Claude Code takes compaction further and turns it into a multi-strategy subsystem. The files under services/compact/ reveal a layered design rather than a single summarization trigger. Conceptually, Claude Code uses at least five defensive layers:

1. Auto-compact — proactive compaction when token use passes a threshold.
2. Snip-compact — selective removal or reduction of older context slices.
3. Micro-compact — minimal surgery, especially clearing heavyweight tool results.
4. Session memory compact — preserve durable extracted memory while compressing transcript history.
5. Context collapse — a stronger restructuring mechanism that commits summarized spans and reconstructs them later.

autoCompact.ts shows a threshold-driven policy with reserved output budget, warning buffers, error buffers, and circuit-breaker logic for repeated failures. This is not a naive “if full, summarize” implementation. It is a production-grade traffic control system.

microCompact.ts shows the lightest-touch strategy: identify compactable tool uses and clear old tool result content. This is especially effective because file reads, shell outputs, grep results, and web fetches often dominate token volume without needing verbatim preservation forever. In other words, Claude Code tries to delete the least semantically valuable tokens first.

sessionMemoryCompact.ts adds another layer: preserve extracted session memory and compact around it while maintaining API invariants such as tool-use and tool-result pairing. This file is full of careful boundary logic, showing how hard real compaction becomes once a transcript contains streaming fragments, tool calls, and thinking blocks.

The “context collapse” mechanism, referenced in transcript entry types such as marble-origami-commit, goes even further. It treats context management as structured archival, not just summarization. This is closer to partial checkpointing than ordinary compaction.

In short, Claude Code treats compaction as a strategic stack, not a single feature.

OMO: compaction with orchestration awareness

OMO inherits OpenCode’s base compaction but adds orchestration-aware safeguards. Three additions are especially important.

1. Preemptive compaction

The preemptive-compaction hook watches token usage after assistant updates and tool executions. When usage reaches a defined fraction of the actual limit, it calls session summarization before a hard overflow occurs. This matters because autonomous multi-agent runs are more vulnerable to abrupt overflow than interactive chat sessions. A preemptive trigger buys safety margin.

2. Compaction context injector

The compaction-context-injector hook strengthens the summary prompt. Instead of relying on a generic “summarize what matters,” it explicitly demands sections for original user requests, final goal, completed work, remaining tasks, active files, constraints, verification state, and delegated agent sessions with session_id values. This is a crucial innovation. OMO knows that summary failure in a multi-agent environment is often not about missing prose; it is about missing execution context.

3. Todo preservation

The compaction-todo-preserver hook snapshots todos before compaction and restores them afterward if needed. This is a subtle but powerful feature. In autonomous workflows, the todo list is not just UI decoration. It is externalized short-term intent. Losing it during compaction can derail the run even if the prose summary is good.

Together these features make OMO less likely to suffer from “successful compaction, failed continuation.” It does not merely shrink context; it protects the scaffolding required to keep working.

graph TD
    subgraph "Claude Code: 5-Layer Defense"
        CC1["Auto-Compact<br/>Token limit trigger"] --> CC2["Snip-Compact<br/>History snipping"]
        CC2 --> CC3["Micro-Compact<br/>Incremental"]
        CC3 --> CC4["Session Memory<br/>Compress memory files"]
        CC4 --> CC5["Context Collapse<br/>Old msgs → summaries"]
    end
    
    subgraph "OMO: Preemptive + Protective"
        OMO1["Preemptive Compaction<br/>Trigger BEFORE overflow"] --> OMO2["Context Injector<br/>Preserve essential context"]
        OMO2 --> OMO3["Todo Preserver<br/>Protect todos during compact"]
    end
    
    subgraph "OpenCode: Summarize & Reset"
        OC1["Detect threshold"] --> OC2["Generate summary"]
        OC2 --> OC3["Reset with summary"]
    end

Tool-result clearing: the lightest touch

Across these systems, the most underrated compaction strategy is tool-result clearing. It is attractive because it minimizes semantic damage. Old bash output, grep listings, and file-read bodies are often useful at the moment of observation but not as permanent prompt residents. Clearing or stubbing them yields large token savings without rewriting the task narrative.

This is why micro-compact style approaches are so important. They act like garbage collection before full checkpointing becomes necessary.

Comparative analysis

OpenCode’s approach is conceptually clean: estimate overflow, summarize, optionally replay the user prompt, and continue. Claude Code’s approach is broader and more defensive: warning thresholds, micro-compaction, session memory, context collapse, and fallback behaviors. OMO extends the OpenCode path with orchestration-preserving hooks that make summaries more continuation-safe.

The tradeoff is complexity versus robustness.

• OpenCode is easier to reason about and easier to extend.
• Claude Code is harder to reason about but more resilient under pathological long-context conditions.
• OMO demonstrates that compaction quality is not only about compression algorithms; it is also about preserving workflow control state.

Design lesson

The best future architecture is probably multi-layered:

1. clear stale tool outputs first,
2. preserve explicit task state such as todos and active files,
3. summarize only when necessary,
4. keep resumable memory artifacts outside the main prompt,
5. reserve a stronger archival mode for very long sessions.

Compaction is therefore less like deleting history and more like building a hierarchy of memory: hot context, warm summaries, and cold archives. Coding agents that master that hierarchy will scale to much longer, more autonomous work without collapsing under their own transcript weight.