Cut What Your Coding Agent Sends to the Model

A coding agent does not send your question. It sends your question plus every tool schema it exposes, plus the whole conversation so far, plus every file it has read this session. That prefix is rebuilt and re-sent on every single turn, so a twenty turn session pays for the same file read twenty times.

This is why the bill grows faster than the work does. The fix is not a smaller model or a shorter prompt. It is compressing the material before it leaves your machine.

headroom, from headroomlabs-ai, is an open source compression layer for AI agents. Apache 2.0, 66,006 stars, and it runs locally so your code never leaves your machine. Its own published measurements on real agent workloads:

1. 1
   Code search over 100 results: 17,765 tokens becomes 1,408. A 92 percent cut.
2. 2
   SRE incident debugging: 65,694 becomes 5,118. Also 92 percent.
3. 3
   GitHub issue triage: 54,174 becomes 14,761. A 73 percent cut.
4. 4
   Codebase exploration: 78,502 becomes 41,254. A 47 percent cut.

Read those numbers carefully, because the spread is the whole lesson. Structured, repetitive material compresses enormously. Dense original prose does not. Where your own savings land depends entirely on what your agent spends its context on.

You will see 60 to 95 percent quoted everywhere. That figure is real, and it is measured on JSON data. For general coding agent traffic the same project publishes 15 to 20 percent. Both numbers are true and they measure different things.

If a claim does not name the workload it was measured on, it is not a number you can plan with

So the honest expectation is this: enormous savings on tool output, logs, search results and JSON. Modest savings on a session that is mostly you and the model writing new prose. Most real sessions are a mix, which is why the measured end to end figures land between the two.

This is the question that actually matters, and it is testable rather than arguable. The published benchmark deltas:

• GSM8K, 100 items: 0.870 baseline against 0.870 compressed. A delta of exactly zero.
• TruthfulQA, 100 items: 0.530 baseline against 0.560 compressed. Slightly better, which is noise at that sample size, not an improvement to believe in.
• SQuAD v2 question answering: 97 percent retained at 19 percent compression.
• BFCL tool calling: 97 percent retained at 32 percent compression.

The reason accuracy holds is worth understanding, because it tells you when it will not. Compression removes redundancy the model was never using: repeated schemas, log preamble, whitespace, boilerplate that appears in every tool result. It is not summarising your reasoning. Push the ratio far enough and you will eventually cut something load bearing, which is why the aggressive numbers appear on JSON and never on prose.

1. 1
   As a proxy. Start it, point your agent at it with a base URL, change nothing else. This is the zero risk way to try it and the way to start.
2. 2
   As a library. Call compress on your messages inline in Python or TypeScript when you want control over exactly what gets touched.
3. 3
   As an agent wrap. One command wraps a specific tool, and one command undoes it. Documented targets include Claude Code, Codex, Copilot, Cursor, Cline, Aider, Continue, Goose and OpenHands.
4. 4
   As an MCP server. Exposes compress, retrieve and stats to any MCP client, so an agent can compress on demand rather than always.