An Empirical Cost Attribution of Context-Compression Gateways in Multi-Turn Coding Agents
Luzhuo Chen and Jiayu Shi (Paritok) instrument their production compression gateway between Claude Code or Codex and Claude Sonnet or GPT-5, and separate the token bill into three levers that save at very different rates. The authors build the gateway being measured.
Ask this paper
Tool-schema filtering. Removing unused tool definitions saves a fixed 21K to 57K tokens per turn, grows linearly with turn count, and is the only lever that was positive in every controlled A/B run.
Content compression. Compressing file reads and tool output saves only about 2% of the cache-priced prefix per turn, but compressed content is re-sent on every later turn, so savings grow about 3350*N^2 tokens and pass tool filtering after roughly 6 turns until the context window caps them.
Recall cost is bounded. When the agent pulls original bytes back, the gateway re-sends exactly one segment, so the cost is fixed per recall rather than multiplied.
Benchmark caution. Paritok-4B keeps 86.5% of SWE-bench quality at a 25.7% compression rate, and the authors state that this single-shot number says nothing about multi-turn cost.
Recipe. Filter tool schemas first, treat compression as a bet on long sessions, keep it non-destructive, report dollars at the correct cache tier, and move toward symbol maps for directed file retrieval.
Abstract
Context compression is widely proposed as a way to cut the token bill of LLM coding agents, and public benchmarks report that aggressive compression preserves task-solving quality. These two facts do not imply the third one commonly assumed: that compressing file reads saves money in a real multi-turn agent. We instrument a production compression gateway (Paritok) between coding agents (Claude Code, Codex) and frontier LLMs (Claude Sonnet, GPT-5), and decompose the token bill of real sessions into three independent levers: tool-schema filtering, content compression of file reads and tool output, and history summarization. Measured in isolation under controlled A/B runs, the three save at fundamentally different rates. Tool-schema filtering removes a fixed block every turn, roughly 21K-57K tokens on a typical turn; it is linear in the turn count N and the only unambiguously and reproducibly positive lever. Content compression saves only about 2% of the cache-priced prefix per turn, but compressed reads accumulate in history and are re-sent on every later turn, so its cumulative saving grows quadratically, about 3350*N^2 tokens (measured), overtaking the fixed tool-filter saving within roughly 6 turns until the context window caps it. A non-destructive gateway lets the agent pull original bytes back on demand; each recall re-sends exactly the one segment just compressed away, so its cost is fixed and bounded rather than a multiplicative blowup, and heavy recall spends the accumulated saving back one segment at a time. Finally, a strong single-shot compression benchmark - 86.5% of SWE-bench quality retained at a 25.7% compression rate, achieved by the model this gateway deploys (Paritok-4B, reported separately) - is orthogonal to multi-turn agent cost and must not be cited as a cost-saving argument. We distill the results into an actionable recipe for where token-saving effort pays off.