An Empirical Cost Attribution of Context-Compression Gateways in Multi-Turn Coding Agents

# An Empirical Cost Attribution of Context-CompressionGateways in Multi-Turn Coding Agents Why Compression Rate Is Not the End-to-End Saving
Source: [https://arxiv.org/html/2609.22114](https://arxiv.org/html/2609.22114)
August 19, 2026

###### Abstract

Context compression is widely proposed as a way to cut the token bill of LLM\-based coding agents, and public benchmarks report that aggressive compression preserves task\-solving quality\. Yet these two facts do not imply the third one everybody assumes: that compressing file reads actually saves money in a real multi\-turn agent\. We instrument a production compression gateway \(Paritok\) sitting between coding agents \(Claude Code, Codex\) and frontier LLMs \(Claude Sonnet, GPT\-5\), and decompose the token bill of real agent sessions into three independent levers: \(i\)*tool\-schema filtering*, \(ii\)*content compression*of file reads and tool output, and \(iii\)*history summarization*\. Measuring each lever in isolation across controlled A/B runs, we find that the three levers save money at fundamentally different rates\. Tool\-schema filtering saves a*fixed*block of tokens every turn \(linear in turn countNN\) and is the only lever that is unambiguously and reproducibly positive; on a typical turn it removes∼\\sim21K–57K tokens\. Content compression, by contrast, saves only∼\\sim2% of the \(cache\-priced\) prefix per turn—but because compressed reads accumulate in history and are re\-sent on every later turn, its cumulative saving grows*quadratically*,≈3,350​N2\\approx 3\{,\}350\\,N^\{2\}tokens \(measured\), overtaking the fixed tool\-filter saving within the first∼\\sim6 turns before the context window caps it\. Crucially, a non\-destructive gateway lets the agent pull the original bytes back on demand, and whenever it does the recall simply re\-sends the bytes just compressed away, so each recall costs a fixed, bounded amount—the length of the one compressed segment it re\-sends, never a multiplicative blowup\. The more the agent recalls, the more of the accumulated content saving is spent back, one compressed segment at a time\. Finally, we show that a strong single\-shot compression benchmark—the 86\.5% SWE\-bench quality retained at a 25\.7% compression rate achieved by the compression*model*the gateway deploys \(Paritok\-4B, reported separately\)—is*orthogonal*to multi\-turn agent cost and must not be cited as a cost\-saving argument for the gateway\. We distill these into an actionable recipe for where token\-saving effort actually pays off\.

## 1Introduction

The dominant cost of an autonomous coding agent is not the model’s output—it is the*input it re\-sends on every turn*\. A modern agent \(Claude Code, Cursor, Codex, OpenHands\) builds each request from three re\-sent parts: a block of tool/function JSON schemas, an ever\-growing message history, and large tool\-result / file\-read blocks\. Because agents solve tasks over many turns of grep, read, edit, and test\[[10](https://arxiv.org/html/2609.22114#bib.bib10)\], this prefix is transmitted dozens of times per task\.

A natural response is*context compression*: shrink the file reads and tool outputs with a small model before they reach the expensive frontier LLM\[[1](https://arxiv.org/html/2609.22114#bib.bib1),[2](https://arxiv.org/html/2609.22114#bib.bib2),[3](https://arxiv.org/html/2609.22114#bib.bib3)\]\. This is attractive and increasingly popular, and a well\-trained compressor can shrink each segment to a quarter of its size while a single\-shot benchmark\[[6](https://arxiv.org/html/2609.22114#bib.bib6)\]shows the downstream model still solves the task\. It is tempting to conclude that such compression proportionally cuts the bill\.

It does not\.In this paper we report a controlled empirical study of*where the tokens actually go*in real multi\-turn agent sessions, and of which interventions actually move the bill\. Our vehicle isParitok, an open\-source non\-destructive compression gateway that intercepts every request, and whose three levers—tool\-schema filtering, content compression, and history summarization—can be independently toggled\. This lets us do something benchmark papers cannot: attribute dollars to levers, in situ, across real agent trajectories\.

Our contributions are:

1. 1\.Acost modelfor multi\-turn agents \(§[2](https://arxiv.org/html/2609.22114#S2)\) that makes explicit why turn count, not compression rate, is the first\-order cost variable, and why cache pricing \(a10×10\\timesdiscount on re\-sent prefix\) changes which savings matter\.
2. 2\.Anisolated measurement of three levers\(§[3](https://arxiv.org/html/2609.22114#S3)\) on real Claude Code and Codex sessions, showing tool filtering is the dominant and only reliably\-positive lever, while per\-turn content compression is a∼\\sim2% marginal effect drowned by turn\-count variance\.
3. 3\.Scaling laws\(§[4](https://arxiv.org/html/2609.22114#S4)\): tool filtering saves linearly inNN, content compression*quadratically*, with a measured crossover nearN≈6N\\\!\\approx\\\!6and a hard cap from the context window\. From a 5\-turn cumulative experiment, the measured content saving fits≈3,350​N2\\approx 3\{,\}350\\,N^\{2\}while the tool filter is a fixed∼\\sim21K/turn\.
4. 4\.Therecall trap\(§[5](https://arxiv.org/html/2609.22114#S5)\): a non\-destructive gateway’s biggest virtue—exact recovery—is also what eats into content\-compression savings, one recall at a time: each recall re\-sends the original it had just compressed, so the compressed copy is wasted—a fixed cost of one compressed segment per recall, equal to the length of that compressed text \(bounded and deterministic, never a multiplicative blowup\)\. The content lever’s net is the accumulated saving minus that per\-recall cost, so its sign is set by recall frequency and session length alone\.
5. 5\.Abenchmark caveat\(§[6](https://arxiv.org/html/2609.22114#S6)\): single\-shot compression quality \(SWE\-bench Lite\) is orthogonal to multi\-turn cost; conflating them is the field’s most common error\.
6. 6\.Methodology\(§[7](https://arxiv.org/html/2609.22114#S7)\) for reproducible agent\-cost measurement: distributions over per\-turn attribution, provider\-reported usage over self\-estimates, cache\-tier accounting\.

We deliberately report the sometimes deflationary picture: a raw*segment*compression rate is not the end\-to\-end saving, which we measure at∼\\sim25% on a single turn and∼\\sim39% by turn five on a long session, reduced by a fixed cost of one compressed segment on each of the minority of turns where the agent recalls the original\. This is the point: it tells a practitioner exactly where to spend effort\.

## 2Setup and Cost Model

### 2\.1Experimental harness

Paritokis a proxy that speaks the Anthropic Messages, OpenAI Chat, and OpenAI Responses protocols, so a coding agent points itsBASE\_URLat the proxy and is otherwise unchanged\. On each request the gateway may \(a\) filter the tool\-schema block down to the semantically relevant tools via a local CPU embedding model\[[9](https://arxiv.org/html/2609.22114#bib.bib9)\], stubbing the rest behind a recall tool; \(b\) compress each file read / tool result with a 4B code\-native compression model \(a LoRA\[[7](https://arxiv.org/html/2609.22114#bib.bib7)\]adapter over Qwen3\-4B\[[8](https://arxiv.org/html/2609.22114#bib.bib8)\]\) to∼\\sim26% of its size, tagging it\[REF:id\]; and \(c\) summarize stale history once the window fills\. Every compression is*non\-destructive*: the agent can call a recall tool \(read\_original,gateway\_search\_tools\) to retrieve exact bytes on demand\.

Each lever can be independently disabled, which is what makes attribution possible\. To isolate content compression we set a token floormin\_tokensto512512\(“compress”\) versus4999949999\(“no\-op”\), holding tool filtering fixed; to isolate tool filtering we toggle it while holding the content path fixed; to remove the confound of MCP tool\-block jitter \(§[7](https://arxiv.org/html/2609.22114#S7)\) we run with\-\-strict\-mcp\-config\.

We run two agent families—Claude Code \(upstream Claude Sonnet\) and Codex \(upstream GPT\-5\)—on real repositories \(textual,jinja2,werkzeug,rich,httpx,tox\)\. Backends are a local Ollama deployment of the 4B model and a GPU server; we verified both compress identically \(segment ratio≈0\.44\\approx 0\.44on line\-numbered reads\)\. All dollar figures use*provider\-reported*usage, priced per tier\.

### 2\.2The bill is a sum over turns, and cache pricing dominates

Let a session run forNNturns\. On turnttthe agent sends a prefixPtP\_\{t\}\(system \+ tools \+ accumulated history \+ reads\) and receives outputOtO\_\{t\}\. Frontier providers price re\-sent prefix at a*cache\-read*tier roughly10×10\\timescheaper than fresh input\. The bill is

Cost=∑t=1N\(ccr​Ptcached\+cin​Ptnew\+cout​Ot\),\\text\{Cost\}\\;=\\;\\sum\_\{t=1\}^\{N\}\\Big\(c\_\{\\text\{cr\}\}\\,P^\{\\text\{cached\}\}\_\{t\}\+c\_\{\\text\{in\}\}\\,P^\{\\text\{new\}\}\_\{t\}\+c\_\{\\text\{out\}\}\\,O\_\{t\}\\Big\),\(1\)with \(Sonnet\)cin=$3c\_\{\\text\{in\}\}=\\$3,ccr=$0\.30c\_\{\\text\{cr\}\}=\\$0\.30,cout=$15c\_\{\\text\{out\}\}=\\$15per million tokens\. Two consequences drive the entire paper:

- •Turn count is the first\-order variable\.The prefixPtP\_\{t\}grows with the conversation and is paid every turn, soCost≈∑tPt\\text\{Cost\}\\approx\\sum\_\{t\}P\_\{t\}is dominated by*how many turns*the agent takes—an emergent property of agent behavior \(how much it reads, edits, explores\), largely orthogonal to compression\. Empirically, the same task on the same config swings from 7 to 18 turns; this variance dwarfs a 2% per\-turn effect\.
- •Not all saved tokens cost the same\.A token removed from the re\-sent prefix is a*cache\-read*token worthccrc\_\{\\text\{cr\}\}, notcinc\_\{\\text\{in\}\}\. We price everything at its actual tier\.

This reframes the question\. Compression does not changeNNdirectly and only shaves a slice off eachPtP\_\{t\}\. So the interesting quantities are:*how large a slice*,*whether that slice grows withtt*, and*whether the intervention perturbsNN*\.

## 3Three Levers, Measured in Isolation

### 3\.1Lever 1 — tool\-schema filtering \(the dominant, stable lever\)

Coding agents advertise their whole toolbox in full JSON schema on every request\. Claude Code sends∼\\sim31 tools \(∼\\sim29K tokens\) with no MCP servers, and 60–90 tools \(44–65K tokens\) once MCP is attached\. Most are irrelevant to the current step\.Paritokkeeps only the handful relevant to the agent’s current intent in full schema and stubs the rest behind a recall tool, freezing the selection per conversation so thetools\[\]block stays byte\-stable \(cache\-friendly\)\.

The effect is large and reproducible\. On single\-file tasks with MCP attached, tool filtering saved392,000392,000tokens over onejinja2session \(∼\\sim32K/request×\\times12\) and1,220,0001,220,000tokens over a 34\-requestrichsession \(∼\\sim36K/request\), against content\-compression savings of18,00018,000and28,00028,000respectively—a raw ratio of20:1 to 33:1in favor of tool filtering \(Table[1](https://arxiv.org/html/2609.22114#S3.T1)\)\.

Table 1:Isolated per\-session savings: tool filtering vs\. content compression \(MCP attached\)\. Tool filtering is billed every request; content compression is counted once per unique file\. Even after multiplying content compression by the turns it rides in history, tool filtering dominates\.A subtle bonus: some clients enlarge the tool block specifically when the endpoint is not the official host\. Measured with Claude Code,base\_url=api\.anthropic\.comyields∼\\sim40K tokens/turn of tools, whilebase\_url=127\.0\.0\.1\(any proxy\) yields∼\\sim57K/turn—a∼\\sim17K/turn “proxy tax\.” Tool filtering not only removes irrelevant tools but cancels this tax, which is why a filtered proxy can beat a direct connection outright \(∼\\sim$0\.043 vs\. $0\.057 on a Sonnet edit task\)\.

Caveat for tool\-poor agents\.Filtering must never stub an agent’s core execution tool\. Codex exposes only∼\\sim9 tools and lives or dies byshell\_command; an embedding filter that intermittently drops it below top\-kkparalyzes the agent \(it stops running commands and asks the user to paste files\)\. We whitelist a set of core execution tools \(shell,exec,apply\_patch, …\) that are never stubbed\. With the whitelist, Codex runs commands every turn; without it, filtering is unsafe\. Correspondingly, tool filtering saves Codex almost nothing \(128–256 tokens\): a 9\-tool agent has no tool bloat to cut\.

### 3\.2Lever 2 — content compression \(a marginal per\-turn effect\)

Compressing file reads to 26% of their size sounds decisive but is, per turn, small: most of a turn’s prefix is the fixed system\+tools\+history, and the compressible file slice is a few percent of it\. In a turn\-aligned comparison \(GPU backend, deduplicated by message id\), the compressed and uncompressed sides are*identical*on turn 0 \(before any file is read\), and thereafter differ by only∼\\sim1\.5–2K tokens/turn—exactly the compressed file slice, entirely in the cheap cache\-read tier \(Table[2](https://arxiv.org/html/2609.22114#S3.T2)\)\.

Table 2:Turn\-aligned prefix, content compression only \(Sonnet/Claude Code,sparklinetask\)\. The per\-turn saving is the compressed file slice \(∼\\sim2K\), all cache\-read\.Because this∼\\sim2%/turn effect is smaller than the turn\-count variance, whole\-task comparisons of “compress vs\. no\-op” come out*time\-varying in sign*: in one multi\-run block the compressed side cost $0\.638 \(18 turns\) vs\. $0\.230 \(7 turns\) uncompressed on the local backend, and the reverse on the GPU backend \($0\.268 at 10 turns vs\. $0\.469 at 16\)\. The difference is entirely turn count \(7/10/13/16/18\), not compression\.*Any*claim about content compression measured on a handful of runs is dominated by this variance; only distributions over≥3\\geq 3runs are trustworthy\.

### 3\.3Lever 3 — history summarization

Summarizing stale turns keeps a long session inside the model’s context window rather than overflowing it \(or forcing an aggressive client\-side compaction that drops detail\)\. Its value is capacity, not primarily dollars, and it interacts with the scaling behavior we analyze next: by shrinking each turn’s prefix, compression and summarization together let the agent fit*more*turns before hitting the window—effectively buying back context length\.

## 4Scaling Laws: Linear vs\. Quadratic

The two content\-bearing levers save at different rates as a session lengthens, and this is the key to when each one matters\. We ran the*same*read\-only “find the bug” task for five consecutive turns in one Claude Code session \(\-\-resume\), with tool filtering left on for both arms so the A/B isolates content compression\. Table[3](https://arxiv.org/html/2609.22114#S4.T3)gives the cumulative savings\.

Table 3:Five consecutive read\-only turns, one session, with tool filtering left on for*both*arms so the A/B isolates content compression\. “Saved” is the measured input difference \(No\-op−\-Compress\); its running sum fits≈3,350​N2\\approx 3\{,\}350\\,N^\{2\}\. The tool\-filter saving is not in this A/B \(on for both arms\); it is the fixed∼\\sim21K/turn established in §[3](https://arxiv.org/html/2609.22114#S3)\.#### Content compression is quadratic\.

The cumulative measured saving \(No\-op−\-Compress input\) is

3466,14051,31712,56412,83710,3466,\\ 14051,\\ 31712,\\ 56412,\\ 83710,which fitsc​N2c\\,N^\{2\}withc≈3,350c\\approx 3\{,\}350\(the per\-N2N^\{2\}ratios lie in3\.353\.35–3\.53×1033\.53\{\\times\}10^\{3\}; the turn\-5 point gives83710/25=334883710/25=3348, reproducing the22\.2%22\.2\\%headline\)\. The mechanism is compounding: each turn reads a file whose compressed form saves a few thousand tokens*that turn*, and because the compressed block stays in history and is re\-sent \(cache\-read\) on every later turn, the per\-turn saving itself grows roughly linearly \(∼\\sim7K/turn\) while its running sum grows quadratically,≈3,350​N2\\approx 3\{,\}350\\,N^\{2\}\.

#### Tool filtering is linear\.

From §[3](https://arxiv.org/html/2609.22114#S3), the unfiltered tool block is∼\\sim29K tokens/turn and the filtered block∼\\sim8K, so tool filtering removes a fixed∼\\sim21K tokens*every*turn, independent of conversation length; cumulative≈21,000​N\\approx 21\{,\}000\\,N\. \(This lever is not visible in Table[3](https://arxiv.org/html/2609.22114#S4.T3), whose A/B keeps the filter on for both arms; it is the per\-turn mechanism, measured against a direct no\-proxy baseline\.\)

#### Crossover and cap\.

Setting3,350​N2=21,000​N3\{,\}350\\,N^\{2\}=21\{,\}000\\,NgivesN≈6N\\approx 6: the fixed tool\-filter saving dominates only for the first∼\\sim6 turns; past that, the compounding content saving overtakes it and the gap widens quadratically \(Figure[1](https://arxiv.org/html/2609.22114#S4.F1)\)\. But the quadratic does not run forever\. The uncompressed prefix is already 87K/turn at turn 5 and grows∼\\sim10–15K/turn, so an unassisted session saturates the∼\\sim200K window around turn 12–15, at which point client\-side compaction truncates history and the accumulation flattens—we already see the per\-turn delta’s growth slow at turn 5 \(\+2598\+2598vs\.∼\\sim70007000earlier\)\. Thus: content compression’s saving grows quadratically*until the window caps it around turn 12–15*, and its own effect \(smaller prefixes\) pushes that cap outward\.

0022446688101012121414002⋅1052\\cdot 10^\{5\}4⋅1054\\cdot 10^\{5\}6⋅1056\\cdot 10^\{5\}8⋅1058\\cdot 10^\{5\}crossoverN≈6N\\\!\\approx\\\!6TurnNNCumulative tokens savedcontent compression≈3,350​N2\\approx 3\{,\}350\\,N^\{2\}tool filter≈21,000​N\\approx 21\{,\}000\\,NFigure 1:Measured content\-compression savings \(markers, from the Table[3](https://arxiv.org/html/2609.22114#S4.T3)A/B\) and fitted scaling laws \(curves\)\. The tool filter is a fixed per\-turn cut \(linear\); content compression compounds \(quadratic\) and overtakes near turn 6, before the∼\\sim200K context window caps the quadratic around turn 12–15\.This is the paper’s central quantitative result:*the two levers are not substitutes but complements with different growth exponents*\. On a single turn the tool filter is the only thing worth measuring; on a long session where the agent seldom recalls, content compression eventually becomes the larger lever\.

## 5The Recall Trap: What Recall Costs Content Compression

A non\-destructive gateway’s defining feature is that nothing is lost: the agent can recall exact original bytes on demand\. Recall is*momentary*: the gateway surfaces the original only for the turn that asks for it and re\-stubs it to its\[REF\]on the very next turn—the agent reads the exact bytes, acts on them, and the original is immediately dropped from the context again \(it never lingers to re\-inflate later prefixes\)\. This is essential for correctness—but it is also precisely what makes each recall cost a fixed, bounded amount—one compressed segment—whenever the agent recalls the original to obtain those exact bytes\.

### 5\.1Isolated evidence: recall costs one compressed segment

We isolated content compression completely \(MCP off, tool filter off—so only the file\-compression path differs\) on a code\-change task \(sparkline\)\. Content compression shrinks each read by only∼\\sim2% of the cache\-priced prefix; but to apply a precise change the agent needs the*exact*bytes, so it recalls the original—and a recall simply re\-sends the segment that was just compressed\. The moment the original returns, the compressed copy the gateway had stored becomes pure waste, of*fixed*size equal to the length of that compressed text\. This is not an error effect: with the edit\-recovery boundary bug fixed \(below\) there were zero reflow typos andEditexact\-match failures were00across all runs, so the recalls are how the agent obtains exact bytes, not a symptom of broken edits\. The cost of recall is therefore bounded and deterministic—one wasted compressed segment per recall—so wherever the agent recalls, the price is exactly that one compressed segment, not a multiplicative cost increase\.

### 5\.2The recall economics

Each recall wastes a*fixed*, bounded amount—the compressed copy of the one segment whose original it re\-sends, since compressing that segment then bought nothing\. It is*not*a fresh full\-prefix round\-trip: the accumulated∼\\sim35K prefix is already cached \(cache\-read,∼\\sim0\.1×\\times\) and would be re\-sent next turn regardless, so the only new cost a recall adds is that single compressed segment\. Crucially the recalled original is*ephemeral*: the gateway resolves it only for the turn that asks and re\-stubs it to its\[REF\]on the next turn, so it never persists to re\-inflate the prefix—the segment does*not*revert to full size for the rest of the session, and the recall stays a one\-time cost\. A recall therefore costs exactly one compressed segment—not a blown\-up bill—and the content lever’s net is the accumulated saving minus one such segment per recall\. How often an agent recalls depends only on how much of the original the change needs:

- •Changes the summary already supports\(e\.g\. setmax\_retries=\-1\): the exact value survives compression, the agent applies it directly, recalls=0\{\}=0, and compression stays marginally positive \(∼\\sim6\.5% fewer total input tokens, all cache\-read—dollar\-neutral\)\.
- •Changes that need the untouched bytes\(e\.g\. a precise multi\-line replacement, where the 4B model had reflowed a retained signature onto one line\): the agent recalls the original \(stably 2 recalls\), each recall costing one compressed segment—a small, bounded loss, not a blowup\.

Recall must not be removed, though: deleting the recall tool entirely is far worse—the agent then reconstructs exact bytes viagrep/cat/re\-reads, reaching 46 turns / $1\.85,3\.2×3\.2\\timesthe cost of keeping recall\.

### 5\.3When content compression nets positive

Combining §[4](https://arxiv.org/html/2609.22114#S4)and §[5](https://arxiv.org/html/2609.22114#S5): content compression’s net is the quadratic accumulation*minus*a bounded cost of one compressed segment per recall, so its sign is set by exactly two variables—*session length*and*how often the agent recalls the original*\. It is positive when both favor it: the session is long \(so the accumulation runs\)*and*recalls are rare \(so little of the saving is spent back\)\. What the task is called does not decide this—only the recall count does: a change the summary already supports needs no recall and stays positive, while one that pulls the original back costs a single compressed segment\. The practical rule is*use more, save more*, with the fine print*many turns, few recalls*\.

## 6A Benchmark Caveat: Single\-Shot Quality⟂\\perpMulti\-Turn Cost

The compression*model*the gateway deploys, Paritok\-4B \(reported separately\), is strong on the standard benchmark: on SWE\-bench Lite\[[6](https://arxiv.org/html/2609.22114#bib.bib6)\]it retains86\.5%of uncompressed solve quality at a25\.7%compression rate, matching a gpt\-4\.1\-mini compressor \(85\.6% at 50\.2%\) at less than half the tokens \(Table[4](https://arxiv.org/html/2609.22114#S6.T4)\)\. We reproduce that number here only to make a point about how it must*not*be read: it is tempting to cite such a benchmark as evidence that “compression saves tokens without hurting the agent\.”*This inference is invalid,*and naming the reason is one of our contributions\.

Table 4:SWE\-bench Lite, single\-shot: context passed through each compressor, one API call, model emits a unified diff\. Quality retained==the compressed arm’s solve quality normalized to the uncompressed baseline, both under the identical single\-shot harness\.The benchmark harness makes*one*API call: it stuffs the \(compressed or full\) context plus the issue into a single user message and asks the model to emit a diff, applied with a fuzzy patcher\. There are no tools, no turns, no re\-reads, no exact\-matchEdit\. It therefore measures*single\-shot understanding under compression*—and shows understanding survives heavy compression\. But a real agent’s cost gap is not in understanding; it is in*multi\-turn behavior and the tool block*, both of which the benchmark omits entirely: it carries no 44–65K MCP tool block \(so it cannot see that tool filtering is the real lever\), it never re\-sends an accumulating prefix, and its fuzzy diff application hides the exact\-match brittleness a realEdittool exposes\. Single\-shot quality and multi\-turn cost are orthogonal axes; a compressor can be excellent on the first and irrelevant—or harmful—on the second\. The 86\.5% \(reported separately for Paritok\-4B\) is best read as a*floor*on understanding, not as a cost claim about the gateway\.

## 7Methodology for Reproducible Agent\-Cost Measurement

Our strongest finding about method is that*per\-turn attribution is unreliable*; agent cost is variance\-dominated and only distributions are trustworthy\. Concretely:

- •Report distributions, not single runs\.The same task swings 2×\\timesin turn count and cost\. We run≥3\\geq 3trials per arm and compare distributions; conclusions drawn from one run repeatedly reversed themselves\.
- •Use provider\-reportedusage, priced per tier\.Cache\-read is∼\\sim0\.1×\\timesthe fresh\-input price; a saving’s tier matters as much as its size\.
- •Control the tool block\.MCP servers load asynchronously and non\-deterministically \(we observed 40 vs\. 90 tools across two concurrent runs, a 40K first\-turn swing\)\. This alone can masquerade as a compression effect; we pin it with\-\-strict\-mcp\-configwhen isolating other levers\.
- •Deduplicate streamed usage\.Client transcripts contain duplicated streaming entries; aggregate by message id\. Server\-side recall is invisible in the client transcript and must be counted via the gateway’s own logs\.
- •Isolate one lever at a timevia themin\_tokensfloor \(content\), a filter toggle \(tools\), andstrict\-mcp\(block size\)—otherwise the proxy tax and MCP jitter contaminate the comparison\.

We also note a genuine code\-level pitfall surfaced by this study: an edit\-recovery routine that re\-aligns a reflowedold\_stringto the real multi\-line file had an asymmetric boundary rule \(prefix reclaimed only" \\t", suffix used\.isspace\(\)\), gluing two tokens across a newline \(max\_widthheight\)\. Making both boundaries use\.isspace\(\)fixed it \(24 recovery tests pass\)\. This is orthogonal to the cost findings but illustrates that non\-destructive recovery has its own correctness surface\.

## 8Recommendations

For practitioners deciding where to spend token\-saving effort on a multi\-turn coding agent:

1. 1\.Filter the tool schema first\.It is the largest per\-turn lever, the only reliably\-positive one, and it grows the agent’s toolbox \(MCP\) without growing the bill\. Keep the selection frozen per conversation for cache stability, and never stub the agent’s core execution tool\.
2. 2\.Treat content compression as a session\-length bet, not a per\-turn win\.It pays off super\-linearly on long sessions where the agent seldom recalls the original \(e\.g\. auditing or Q&A over a large codebase\), and on short sessions or the minority of turns where the agent recalls it costs at most one compressed segment—bounded, never a multiplicative loss\.
3. 3\.Keep compression non\-destructive, but budget for recall\.Exact recovery is required for correctness; just subtract one compressed segment’s saving on any turn where the agent recalls\.
4. 4\.Report end\-to\-end dollars at the correct cache tier, and never cite a single\-shot benchmark as a multi\-turn cost result\.
5. 5\.The next frontier for file\-level value is a symbol map / directed retrieval—be the agent’sgrep\(which functions exist, at which lines, fetch the exact span on demand\)—rather than indiscriminate body deletion, which agents route around by slice\-reading and which harms editing\.

## 9Related Work and Limitations

Prompt\-compression methods—token pruning \(selective\-context\[[3](https://arxiv.org/html/2609.22114#bib.bib3)\], the LLMLingua family\[[1](https://arxiv.org/html/2609.22114#bib.bib1),[2](https://arxiv.org/html/2609.22114#bib.bib2)\]\) and soft\-prompt compression \(gist tokens\[[4](https://arxiv.org/html/2609.22114#bib.bib4)\], AutoCompressors\[[5](https://arxiv.org/html/2609.22114#bib.bib5)\]\)—optimize single\-prompt compression rate and downstream quality, the same axis as our SWE\-bench measurement; our contribution is to show that this axis is orthogonal to multi\-turn agent*cost*\. Gateway/proxy context managers that summarize conversation history address lever 3 but leave the file/tool content—the fastest\-growing part of the bill—untouched; skeleton\-extraction tools reduce reads to signatures but force the re\-expansion round\-trips our recall analysis quantifies\.

Our study has clear limits\. Numbers are from a specific 4B compressor, two agent families, and Python\-heavy repositories; the scaling*exponents*\(linear/quadratic\) should generalize, but constants will not\. The quadratic fit rests on five turns; while the mechanism \(re\-sent accumulating history\) makes theN2N^\{2\}form near\-inevitable, the cap’s exact turn depends on window size and client compaction policy\. Codex\-on\-Windows introduced shell\-encoding noise orthogonal to compression\. We report ranges and distributions accordingly\.

## 10Conclusion

“Compress the file reads” is the intuitive way to cut a coding agent’s token bill, and it is mostly the wrong lever\. We decomposed real multi\-turn agent cost and found that \(i\) turn count, not compression rate, sets the bill; \(ii\) tool\-schema filtering is the dominant, reproducibly\-positive lever, saving a fixed block linearly every turn; \(iii\) content compression is a∼\\sim2% per\-turn effect that nonetheless accumulates*quadratically*over a long session and overtakes the tool filter near turn 6 before the context window caps it; \(iv\) each recall costs a bounded, fixed amount—one compressed segment—eroding the content saving only in proportion to the \(minority\) recall count; and \(v\) single\-shot compression benchmarks are orthogonal to multi\-turn cost\. The practical takeaway is a hierarchy: filter tools always, compress content when the session is long and the agent rarely recalls, and measure in end\-to\-end dollars at the right cache tier\. Decomposition, not a headline compression rate, is what tells you where the tokens actually go\.

#### Reproducibility\.

## References

- \[1\]H\. Jiang, Q\. Wu, C\.\-Y\. Lin, Y\. Yang, and L\. Qiu\.LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models\.In*Proc\. EMNLP*, 2023\. arXiv:2310\.05736\.
- \[2\]Z\. Pan, Q\. Wu, H\. Jiang, M\. Xia, X\. Luo, J\. Zhang, Q\. Lin, V\. Rühle, Y\. Yang, C\.\-Y\. Lin, H\. V\. Zhao, L\. Qiu, and D\. Zhang\.LLMLingua\-2: Data Distillation for Efficient and Faithful Task\-Agnostic Prompt Compression\.In*Findings of ACL*, 2024\. arXiv:2403\.12968\.
- \[3\]Y\. Li, B\. Dong, C\. Lin, and F\. Guerin\.Compressing Context to Enhance Inference Efficiency of Large Language Models\.In*Proc\. EMNLP*, 2023\. arXiv:2310\.06201\.
- \[4\]J\. Mu, X\. L\. Li, and N\. Goodman\.Learning to Compress Prompts with Gist Tokens\.In*Advances in Neural Information Processing Systems \(NeurIPS\)*, 2023\. arXiv:2304\.08467\.
- \[5\]A\. Chevalier, A\. Wettig, A\. Ajith, and D\. Chen\.Adapting Language Models to Compress Contexts\.In*Proc\. EMNLP*, 2023\. arXiv:2305\.14788\.
- \[6\]C\. E\. Jimenez, J\. Yang, A\. Wettig, S\. Yao, K\. Pei, O\. Press, and K\. Narasimhan\.SWE\-bench: Can Language Models Resolve Real\-World GitHub Issues?In*Int\. Conf\. on Learning Representations \(ICLR\)*, 2024\. arXiv:2310\.06770\.
- \[7\]E\. J\. Hu, Y\. Shen, P\. Wallis, Z\. Allen\-Zhu, Y\. Li, S\. Wang, L\. Wang, and W\. Chen\.LoRA: Low\-Rank Adaptation of Large Language Models\.In*Int\. Conf\. on Learning Representations \(ICLR\)*, 2022\. arXiv:2106\.09685\.
- \[8\]Qwen Team\.Qwen3 Technical Report\.arXiv preprint arXiv:2505\.09388, 2025\.
- \[9\]S\. Xiao, Z\. Liu, P\. Zhang, and N\. Muennighoff\.C\-Pack: Packaged Resources To Advance General Chinese Embedding\.arXiv preprint arXiv:2309\.07597, 2023\.
- \[10\]S\. Yao, J\. Zhao, D\. Yu, N\. Du, I\. Shafran, K\. Narasimhan, and Y\. Cao\.ReAct: Synergizing Reasoning and Acting in Language Models\.In*Int\. Conf\. on Learning Representations \(ICLR\)*, 2023\. arXiv:2210\.03629\.