Context compression cuts the tokens a model reads on each request while keeping what it needs to answer. For agents, that means shrinking the history, file contents and tool output re-sent every turn. The main methods are truncation, summarization (compaction), token pruning and tool-output filtering. All are lossy, so the test is whether the agent still finishes the task for less.
Why it exists
Model APIs are stateless, so an agent re-sends the system prompt, tools and whole conversation on every call. The window fills and old history is paid for again each turn.
- default
- with compression
- cache read67.7%
- cache write18.9%
- output13.2%
- fresh input0.2%
The main methods
Each method trades tokens for a different kind of risk. Deep dives: /compact vs /clear, prompt compression explained and how to compress tool output.
| Method | What it does | Main risk |
|---|---|---|
| Truncation | Drops the oldest messages or cuts long outputs | Loses early instructions and decisions |
Summarization (/compact) | Rewrites history into a shorter summary | Summaries drop specifics like paths and error text |
| Token-level pruning | Removes low-information words, keeps the rest verbatim | Can break identifiers and code |
| Tool-output filtering | Trims logs and search results, from | tail -n 50 to rtk | Can hide the one line that mattered |
| Selective loading | Reads only what the step needs; subagents explore in their own context | Agent misses context it did not know to ask for |
Tokens removed is not money saved
Most tools report the share of tokens removed. Three things decide the bill instead.
- The cache. Rewriting earlier context forces fresh cache writes, which cost more than normal input.
- Which part shrinks. Fresh input is a tiny share; history re-read from cache is the large one.
- Re-fetching. If the agent re-reads what was dropped, the saving can vanish.
Did it hurt your agent?
Exact next actions are a poor test: an uncompressed rerun matched its own original only 10-46% of the time (our quality evaluation).
- 1Pick real tasks
Work your team does every week, not single-shot benchmarks.
- 2Run with and without
Same model, several runs each, since agents take different valid routes.
- 3Compare the outcome
Tasks solved, total spend, and how often the agent re-reads files.
How condense does it
condense is a hosted proxy that combines extractive and abstractive compression. Your instructions, user messages and final answers are never changed.
- 1Helene trims the newest turn
Extractive, word for word, before it is first cached. Never touches code, patches or errors.
- 2Adeline packs finished loops
Short summaries that keep intents, paths, identifiers, errors and code.
- 3Packed history is frozen
The provider keeps serving it from cache. A 200-turn Opus session held goal quality at 62% fewer tokens; below about 20 turns the overhead outruns the saving.
Frequently asked questions
What is the difference between context compression and token compression?
They are used almost interchangeably. Token compression usually means removing tokens from a prompt, as LLMLingua does; context compression also covers summarizing history and filtering tool output.
What is context compaction?
Compaction is the agent-tool term for summarizing a long conversation so it fits the window. Claude Code does it automatically when the window fills, or on demand with /compact.
Does context compression reduce accuracy?
It can, if it drops a decision the agent needed, and it can help by leaving less to get distracted by. Measure task success on your own work.
Is prompt caching a form of context compression?
No. Caching bills repeated tokens at a discount while compression sends fewer tokens; they stack when the compressor keeps the cached prefix stable.
When is context compression not worth it?
On short sessions and small prompts, where overhead can outrun the saving. In our measurements, condense breaks even around turn 20.