Does context compression lower your bill?

Why fewer tokens is not a lower bill

A coding agent is a loop. The model asks for a tool, the harness runs it, and the result is appended to the conversation. The next request sends that whole conversation back. Most of what you pay for is the prefix being replayed, not the one new file.

Providers do not price every input token the same. Anthropic’s prompt-caching docs price a five-minute cache write at 1.25 times the base input rate, a one-hour write at 2 times, and a cache read at 0.1 times for most models. OpenAI’s prompt-caching guide uses the same shape on GPT-5.6 and later: cache writes at 1.25 times uncached input, subsequent reads at 0.1 times on most of those models. A cache hit is cheap. Busting the prefix and writing it again is not.

Three other facts sit next to that pricing. Compressing what the model reads does not shrink the tokens it writes, which are billed at the output rate either way. If compression drops a line the agent needed for an exact edit, the model re-reads or retries; each extra turn pays the prefix again, plus new output. And a tool that only intercepts shell stdout never sees built-in Read, Grep, Glob, or most MCP results, so a large reduction on that slice can be a rounding error on the session.

What independent measurements show

These studies do not all test the same tools. Several are written by vendors; that is noted. What they share is paired sessions and a bill, not a counter on one compressed blob.

• Token Reduction Is Not Cost Reduction (PointFive; affiliation disclosed) ran paired, provider-billed Claude Code tasks. The most aggressive setup they report reduced delivered tool-output tokens by 38.4% and increased billed cost by 6.8%. Prompt-cache traffic dominated the input-side bill.
• Glia Intelligence’s RTK benchmark compared 18 low-effort Opus 5 runs with RTK to 18 without. RTK’s counter estimated 76% less shell output. Claude Code reported 5.8% more total cost with RTK. Some tasks were cheaper, some more expensive; the shell-output saving was not a reliable cost saving.
• Rakuen Software (maker of aimee; disclosed) cites a JetBrains paired RTK trial: across 80 clean low-effort Claude Code pairs, median cost per task rose 7.6%, turns rose 13.8%, and cache reads rose 14.3%. At high effort, cost was statistically tied. Quality was tied in both arms.
• Cache-Aware Prompt Compression (Yan Song) isolates the cache-bust. On 50 tau-bench retail tasks, query-aware compression — a different compressed prefix per query — cost 40.1% more than an uncompressed baseline at the same reward. A cache-preserving compressor on the same suite cost 7.9% less, with the same 36 of 50 tasks completed.
• codepointer.dev replayed rtk, headroom, and caveman over a 614M-token sample of real Claude Code sessions. Combined, the three saved 3.7% of spend. In that corpus, 78% of tool-output tokens never reached rtk’s shell hook — almost all of it the native Read tool.
• Tokenade’s THOL write-up (vendor; disclosed) reports rtk at about break-even on session cost and headroom 53% above running no tool.
• The Torana tool-output compaction measurement (vendor; disclosed) found a median paired saving of ~2.1% per session on DeepSeek V4 Pro, smaller than run-to-run variation, with about 92% of input tokens already cache hits. An earlier design that summarised file reads broke exact-match edits and caused re-read loops.

None of this says compression can never pay — Song’s cache-preserving arm did. Chen and Shi (Paritok; disclosed) argue that shrinking file reads can compound over a long session, and that recalling the original spends that saving back. Payload token reduction is not a forecast of the invoice.

When compression can help, and when it can raise the bill

Help: compress new content before its first cache write. The first time a log, grep dump, or MCP result enters the conversation, it is written to the cache at the write rate and then re-read cheaply. Making that first write smaller, without changing anything already cached, is the case the pricing tables reward.

Hurt: rewriting or summarising history. Changing bytes behind the cache breakpoint turns a cheap read into a new write, and the rest of the prefix is billed as fresh until the cache is rebuilt. PointFive’s 2026 prompt-compression guide puts it plainly: a compressed prompt that misses the cache can cost more than an uncompressed prompt that hits it. Evaluate caching and compression together.

Hurt: coverage that misses the real tokens. Command-output filters help with noisy git, test, and build stdout. They do not see Claude Code’s built-in Read, Grep, and Glob paths, or most MCP results, unless those run through the shell. Glia, the JetBrains trial Rakuen cites, and codepointer all run into that gap. If your sessions are mostly file reads, a shell-only saving will not show up on the bill.

Hurt: lossy summaries that the agent must repair. Coding agents apply patches by matching exact lines. Torana documented re-read loops after summarising file reads; PointFive documented ranked search summaries breaking shell pipelines that expected original grep lines. Extractive keeping of original lines avoids that class of failure; abstractive summaries have to prove they do not introduce it.

How to measure it yourself

Do not multiply a token-reduction percentage by your whole bill. That product assumes every token is uncached input and that the agent takes the same number of turns. A workable test:

1. Pair the runs. Same repo, same task, same model and effort, with and without the tool. Repeat, and randomise order inside each pair. Keep an uncompressed control; client and model drift will move the bill on their own.
2. Score the work, then the money. Count a run only if the task was actually solved. daseinlabs/code-compression-bench ranks layers by cost per solved task: cache-aware total cost divided by tasks the grader passed. A cheaper run that fails the task is not a saving.
3. Use the provider’s usage fields. Uncached input, cache writes, cache reads, and output, each at that model’s published rate. A “tokens saved” counter that never sees cache or output cannot contradict the invoice.
4. Count failures and extra turns. Extra file reads and extra tool calls are how a local saving disappears. If the treatment side takes more turns, ask whether the compressor dropped something the agent had to go back for.

For how the different tool families act, see context compression for coding agents.

Where SuperCompress sits

SuperCompress is hosted, extractive, and query-aware. It compresses new bulky tool results and other large context — logs, diffs, file reads, MCP results — before those bytes enter the conversation, and it leaves earlier turns untouched. That is the cache-friendly pattern: shrink the live tail, do not rewrite the cached prefix. The agent sends the bulky block as context and the current question as query. SuperCompress keeps the original lines that answer that question and drops the rest, so file paths, error messages, IDs, and code come through as the tool returned them. The question itself is never compressed. Every response reports original_tokens and kept_tokens. This page does not claim SuperCompress has been shown to lower anyone’s bill; the only honest number is a paired measurement on your sessions.

Install

One command finds the coding agents on your machine and adds SuperCompress to each of them:

npm install -g supercompress-proxy && supercompress setup

Then run supercompress doctor to check what is connected. The full harness list is in the coding agents guide.

FAQ

Does context compression lower your bill?

Not automatically. Paired tests keep finding that a large drop in tokens on one payload can sit next to a flat or higher session bill. Measure cache-aware cost per solved task on your own work.

Why does prompt caching change the math?

Agents resend the conversation prefix every turn. A cache hit is billed at a fraction of fresh input; a new cache write costs a premium. Input compression does not change output tokens. Rewriting earlier turns turns a cheap read into an expensive write.

How should I measure a compression tool?

Run the same tasks with and without it. Compare cost per solved task from provider cache-read, cache-write, uncached-input, and output usage. Count failures and extra turns. Do not multiply a tokens-removed percentage by your whole bill.

Does SuperCompress rewrite earlier turns?

No. It compresses new bulky tool results and context before they enter the conversation and leaves earlier turns untouched. It keeps the original lines that answer the current question and drops the rest.

Can I use SuperCompress with Claude Code, Codex, or Cursor?

Yes. Run npm install -g supercompress-proxy && supercompress setup, then supercompress doctor.

Get API key Coding agents guide Approaches compared