You pay for input tokens. Compression only helps if the model still gets the facts it needs. SuperCompress is built to cut waste without cutting the answer.
Updated 2026-08-01 · held-out answer containment · live compiler workloads
Keep the answer. Drop the noise.
Most compressors cut tokens. SuperCompress is judged on a harder question: after compression, can the model still answer correctly? On primary held-out suites (real / fresh4 / fresh5), gold answers survive at 99.4% pooled (180/181) while mean token cut stays ≥55%. Fresh6 cold mix also clears the answer gate below.
Held-out answers
99.4%
Pooled gold containment on real + fresh4 + fresh5 (seeds 4242 / 9091 / 6161).
Mean cut
~58–66%
Token-weighted cut ~62–69% on the same held-out mixes — no restore-to-98% floor.
Oracle suite
100%
Fixed 35% budget oracle recall on the public 8-seed suite (vs ~25% truncation).
Runtime
~47ms
CPU policy path. Hosted neural ranking optional. No extra LLM call.
Why these numbers matter
We measure whether answer-bearing lines survive. Fixed-budget head-to-head: SuperCompress 100%, H2O 97.9%, summarization 60.5%, truncation/FIFO 24.8%.
Logs, RAG chunks, chat history, tool output — compiler mode removes everything it can while locking query-critical evidence. Savings scale with how noisy the dump is.
neural ranking, ~47ms on CPU, no GPU queue, no second model call. Drop it in front of OpenAI, Claude, Gemini, or local models.
Same budget. Who keeps the answer?
Fair test: every method keeps only 35% of tokens. The only question is whether the answer-critical lines are in that 35%.
| Method | Answer-critical kept | What that means | Latency | Footprint |
|---|---|---|---|---|
| FIFO / Truncation | 24.8% | Drops the middle — often where the answer lives | ~42–46 ms | Rule-based |
| Summarization | 60.5% | Rewrites context; can invent or omit details | ~48 ms + LLM | Extra model call |
| H2O | 97.9% | Strong attention baseline from serving research | ~42 ms | Attention-heavy |
| SuperCompress Best | 100% | Every answer-critical line kept | ~47 ms | neural ranking, CPU |
How SuperCompress compares to common alternatives
| Baseline | Query-aware? | Public result / claim | Why teams still pick SuperCompress |
|---|---|---|---|
| Headroom | Mostly type / tool-output aware | Publicly claims ~15–20% fewer tokens for coding agents | We score directly against the question and report answer-critical retention |
| Rule heuristics / Caveman-style | No | Prompt-dependent shortcuts | Query-aware ranking instead of fixed windows |
| Truncation | No | 24.8% critical kept on this suite | Preserves critical lines anywhere in the context, not just head/tail |
| H2O | Yes (attention) | 97.9% on this suite | Higher critical retention here, with a tiny CPU policy instead of attention eviction |
| SuperCompress | Yes | 100% critical kept | Best quality metric + smallest practical footprint |
Compiler mode — remove everything you can, keep everything important
No fake “keep 35%” floor. Compiler mode drops non-essential context until only what’s needed for the question remains — then verifies that answer-critical content is still there. Noisy dumps compress hard. Dense coding context compresses less. That’s intentional.
| Workload | Original | After | Removed | Savings | Critical kept |
|---|---|---|---|---|---|
| Literature study context | 1,454 | 1,052 | 402 | 27.6% | 100% |
| Dense coding session | 1,020 | 397 | 623 | 61.1% | 100% |
| Docs / markdown | 1,195 | 59 | 1,136 | 95.1% | 100% |
| Agent incident log | 1,074 | 232 | 842 | 78.4% | 100% |
| Token-weighted average | 1,186 | 435 | 751 | 63.3% | 100% |
Held-out answer containment (anti-overfit)
Separate from the fixed-budget oracle suite: compress real LongBench dumps + brand-new OOD wiki/RFC/README haystacks, then check whether the gold answer string is still present. Gates: ≥98% answer retention, ≥55% mean cut, ≥55% token-weighted cut. No circular restore floor.
| Suite | Seed | Answer kept | Mean cut | Token-weighted cut | Gates |
|---|---|---|---|---|---|
| Real (ood_fresh3 + hotpot/2wiki/multifield/qasper) | 4242 | 98.4% (61/62) | ~57.8% | ~64.7% | pass |
| Fresh4 (ood_fresh4 + musique/trivia/narrative/samsum) | 9091 | 100% (57/57) | ~66.1% | ~68.8% | pass |
| Fresh5 (ood_fresh5 + hotpot/2wiki/multifield/qasper) | 6161 | 100% (62/62) | ~57.8% | ~61.6% | pass |
| Fresh6 cold (ood_fresh6 hard + musique/trivia/narrative/2wiki) | 3377 | 98.6% (70/71) | ~68.2% | ~72.5% | pass |
At a glance
Impact when this runs at scale
SuperCompress removes prompt text before inference, so fewer tokens reach the GPU and the provider performs less prefill work. Estimates use documented assumptions (2,500 tok/GPU-s, 150W GPU, an estimated 55% inference-memory share for provider-managed KV state, 0.417 kg CO₂/kWh) and ~800 tokens saved per call.
| Scale | Tokens avoided | kWh saved | CO₂ avoided |
|---|---|---|---|
| 1,000 calls | ~800K | ~0.03 | ~0.01 kg |
| 1M calls | ~800M | ~29 | ~12 kg |
| 10M calls | ~8B | ~290 | ~120 kg |
Questions people actually ask
What is “answer-critical” / oracle recall?
It’s the share of lines that contain the information needed to answer the question that still appear after compression. 100% means nothing required for a correct answer was deleted. That’s the metric that protects quality.
Why do all methods show ~65% tokens saved in the first table?
Because that test forces the same budget: keep 35% of prompt tokens, drop 65%, so tokens_saved_pct is ~65% for every method. It’s a quality contest, not a savings contest. The interesting number is who still has the answer afterward.
Why do savings vary by workload?
Noisy dumps (logs, markdown chrome, agent traces) compress hard — often 70–95%. Dense literature or tightly relevant coding context keeps more by design. The preset suite averages ~63% token-weighted savings with 100% critical retention.
Is this better than just truncating my prompt?
At the same size budget, truncation kept ~25% of critical lines on our suite. SuperCompress kept 100%. Truncation is fine when the answer is always at the edges. Real agent and RAG dumps put the answer anywhere.
Do I need a GPU?
No. SuperCompress runs on CPU with a learned query-aware neural policy and ~47ms average latency on the suite. Zero GPU time, zero extra LLM calls.
Can I try it on my own traffic?
Yes — use the playground, the hosted API, or the coding-agent MCP plugin. You’ll see tokens removed and critical-retention metadata on each call.
Try SuperCompress on your own context
Paste your long prompts and see exactly how much can be removed while keeping what matters.