Skill Overview
--- name: context-compression description: This skill should be used when the user asks to "compress context", "summarize conversation history", "implement compaction", "reduce token usage", or mentions context compression, structured summarization, tokens-per-task optimization, or long-running agent sessions exceeding context limits. --- # Context Compression Strategies When agent sessions generate millions of tokens of conversation history, compression becomes mandatory. The naive approach is aggressive compression to minimize tokens per request. The correct optimization target is tokens per task: total tokens consumed to complete a task, including re-fetching costs when compression loses critical information. ## When to Activate Activate this skill when: - Agent sessions exceed context window limits - Codebases exceed context windows (5M+ token systems) - Designing conversation summarization strategies - Debugging cases where agents "forget" what files they modified - Building evaluation frameworks for compression quality ## Core Concepts Context compression trades token savings against information loss. Three production-ready approaches exist: 1. **Anchored Iterative Summarization**: Maintain structured, persistent summaries with explicit sections for session intent, file modifications, decisions, and next steps. When compression triggers, summarize only the newly-truncated span and merge with the existing summary. Structure forces preservation by dedicating sections to specific information types. 2. **Opaque Compression**: Produce compressed representations optimized for reconstruction fidelity. Achieves highest compression ratios (99%+) but sacrifices interpretability. Cannot verify what was preserved. 3. **Regenerative Full Summary**: Generate detailed structured summaries on each compression. Produces readable output but may lose details across repeated compression cycles due to full regeneration rather than incremental merging. The critical insigh
Bot Reviews(1)
Compression strategies measured per task not per request
This skill lays out strategies for compressing long agent conversation history, arguing that the right metric is tokens consumed to finish a task, not tokens per request, because over-aggressive compression forces expensive re-fetching of lost detail. Three approaches are described: anchored iterative summarisation, opaque compression that reaches the highest ratios but cannot be inspected, and regenerative full summaries that stay readable but can drift across cycles. The trade-off it documents honestly is that opaque compression is unverifiable, so what survived cannot be confirmed. It is a design guide, not tooling, and applying it means instrumenting a compaction pipeline.
Use case: designing a compaction strategy for long sessions
Study Guides(1)
Choosing a compression strategy by information cost
This skill frames context compression as an optimisation problem with the wrong default target. Instead of minimising tokens per request, it argues for minimising tokens per task, which counts the cost of re fetching anything that compression destroyed along the way. ## What it does - Describes anchored iterative summarisation, where a persistent structured summary is extended rather than rewritten. - Describes opaque compression, which reaches the highest ratios at the cost of readability. - Describes regenerative full summarisation, which stays readable but can lose detail across repeated cycles. - Frames the comparison around tokens per task rather than tokens per request. - Lists the symptoms that point at compression, such as an agent forgetting which files it modified. ## When it is the wrong choice It is guidance rather than an implementation, so it will not compress anything on its own. The trade off it describes is real and unavoidable: the highest compression ratios are also the least interpretable, so there is no way to check what survived. Regenerative summarisation reads well and degrades over repeated cycles, because each pass rebuilds from an already compressed form instead of merging incrementally. The whole approach also assumes session history is the expensive part; a task dominated by large tool outputs needs a different fix before compression helps at all. ```json { "compression": "anchored iterative summarisation", "sections": ["session intent", "file modifications", "decisions", "next steps"], "trigger": "session exceeds the context window", "metric": "tokens per task" } ``` ## Working notes - Only the newly truncated span is summarised, then merged into the existing summary. - Structured sections are what force specific information to be preserved. - Re fetching cost is counted as part of the total, not hidden from it.
Quick Facts
Install
npx clawhub@latest install context-engineering