context-compressionlisted

# 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 Use / Not Use **Use 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 **Do NOT use when:** - Diagnosing why context is degrading -> use `context-degradation` - KV-cache optimization or context partitioning -> use `context-optimization` - Learning foundational context theory -> use `context-fundamentals` - File-based offloading or scratch pads -> use `filesystem-context` ## Decision Tree ``` Why do you need compression? ├── Agent sessions hitting context limits │ ├── What matters most? │ │ ├── File tracking + decision history (long sessions) -> Anchored Iterative Summarization │ │ ├── Maximum token savings (short sessions, low re-fetch cost) -> Opaque Compression │ │ └── Readability + phase boundaries -> Regenerative Full Summary │ └── Not sure? -> Start with Anchored Iterative (best quality trade-off) ├── Need to measure if compression is work