Good question to resolve before we finalize the post. Let me map this properly — because the answer is "Headroom covers more than RTK but it doesn't cover the full picture, and the gaps are specific."
Coverage Map: RTK + Headroom vs. the Full Non-Shell Token Problem
| Token bloat source | RTK | Headroom | Gap / Alternative |
|---|---|---|---|
| Shell command stdout | ✅ Native | ✅ Via bundled RTK | Fully covered |
| JSON tool results (repeated schema) | ❌ | ✅ SmartCrusher | Covered — structural deduplication |
| JSON API responses (field bloat) | ❌ | ⚠️ Partial | SmartCrusher strips structural redundancy; it does NOT filter irrelevant fields |
| Source code blobs | ❌ | ✅ CodeCompressor | Covered — AST-aware |
| RAG chunks (post-retrieval) | ❌ | ⚠️ Partial | Kompress compresses prose after retrieval; does NOT reduce which chunks enter context |
| RAG chunks (pre-retrieval filtering) | ❌ | ❌ None | Gap — FlashRank / Cohere Rerank |
| Prose documents | ❌ | ✅ Kompress | Covered at sentence level — but non-deterministic |
| Token-level prose compression | ❌ | ❌ None | Gap — LLMLingua operates at word/token level, far more aggressive |
| Short-session chat history | ❌ | ✅ Kompress | Covered — extracts low-signal turns |
| Long-session rolling history | ❌ | ❌ None | Gap — Headroom compresses individual messages; no compaction/summarization strategy |
| Session memory as knowledge graph | ❌ | ❌ None | Gap — Mem0 / Supermemory — different paradigm entirely |
The Three Meaningful Gaps
Gap 1 — Pre-retrieval filtering (the upstream problem Headroom ignores)
Headroom's Kompress compresses prose after it lands in context. But the more efficient intervention is before retrieval — sending the top 3 chunks to the model instead of the top 20. That's what FlashRank and Cohere Rerank do: lightweight cross-encoder reranking that aggressively drops low-relevance chunks before they touch the agent's context window at all.
This is architecturally a different intervention point. Headroom compresses what's already there. Reranking controls what arrives in the first place. For RAG-heavy pipelines, these are complementary — rerank first to reduce chunk count, Headroom compresses the survivors. For your deep_research_agent specifically, adding a FlashRank rerank pass on DuckDuckGo results before they hit the agent's context would reduce token volume before Kompress even sees them.
FlashRank is fully local (Rust, ~5MB model, sub-5ms latency). Cohere Rerank is hosted. For your local-first, compliance-adjacent stack — FlashRank.
Gap 2 — Token-level prose compression (LLMLingua's different intervention)
Headroom's Kompress is extractive at the sentence level — it scores sentences and removes the low-scoring ones. LLMLingua (and LongLLMLingua for longer documents) is extractive at the token/word level — it calculates perplexity on individual tokens using a small local model (Mistral, LLaMA-3) and removes low-information tokens from within sentences. That's a fundamentally more aggressive compression approach.
The claims in your research doc (20x compression, 95% reasoning retention) are benchmark numbers from their paper, not general baselines — they vary heavily by content type. But the approach is legitimate and more aggressive than Headroom's sentence extraction.
The problem: LLMLingua has the same non-determinism issue as Kompress, and arguably worse — word-level removal has higher semantic risk than sentence-level removal. A qualifying clause can survive sentence-level extraction but get its key modifier token dropped at word level. For compliance-adjacent work, the audit risk increases, not decreases, vs. Kompress. For pure cost optimization where auditability isn't a constraint — it's worth benchmarking.
Gap 3 — Long-session rolling history (no compaction strategy in Headroom)
Headroom compresses individual messages as they pass through the pipeline. It doesn't have a concept of "once the context hits 4,000 tokens, compact the oldest 3,000 into a paragraph of state facts and discard the raw turns." That's what rolling compaction does — and it's what a long-running ambient agent genuinely needs.
Mem0 and Supermemory take this further: they convert session history into a vector knowledge graph rather than compressed text. The agent retrieves relevant facts from memory rather than receiving a transcript. This is a completely different paradigm from compression — it's memory management, not token reduction.
For your Hermes-on-VPS ambient agent use case, a rolling compaction strategy is the right fit (lighter dependency, explicit control). For a product where session continuity and cross-session memory matter, Mem0's approach is architecturally stronger.
What This Means for the Series
Does Headroom cover all scenarios? No. It covers the content compression layer well — structural JSON, code, sentence-level prose, individual message history. It doesn't cover pre-retrieval filtering, token-level prose compression, or long-session compaction strategy.
Is that a gap in the series? Yes — but a specific and honest one. The current Part 3 positions Headroom as "what compresses the non-shell half," which is accurate for the content compression layer. It's incomplete if a reader takes that to mean "Headroom + RTK = complete token management."
Three paths for how to handle this:
Option A — Add a "What Headroom Doesn't Cover" section to Part 3. A coverage table + one paragraph each on pre-retrieval filtering and rolling compaction. Adds ~400 words. Keeps Part 3 honest about Headroom's scope without bloating it into a landscape survey.
Option B — Part 4: The Full Context Engineering Landscape. "RTK + Headroom cover the compression layer. Here's the retrieval layer, the memory layer, and where each one earns its complexity." This maps cleanly to the series's progression — Part 1 is reliability, Parts 2–3 are shell and content compression, Part 4 is the complete picture. This also sets up your RAG domain series (wealth management, healthcare) as the applied layer on top.
Option C — Keep Part 3 as-is, add one closing sentence. "Headroom covers content compression; pre-retrieval filtering (FlashRank) and long-session compaction (rolling summary or Mem0) are separate concerns addressed at different layers." Minimal addition, honest scope-setting, leaves the fuller treatment for Part 4.
My recommendation: Option A if you want Part 3 complete-in-itself; Option B if this feels like its own piece (it has enough material for a standalone landscape article). Option C if you want to ship Part 3 now and revisit.
What's your call?