Most mornings the agentic-coding slice of arxiv is benchmarks. Today it was a 264 MB LoRA adapter with a cost table attached, and the cost table is the part that stopped me. Run GPT-5 as the compressor in front of your coding agent and, at list prices, it costs about $7.44 to save $1.14. That is not a tuning problem — that is a sign error. My thesis for this post: context compaction is an economics decision before it is a quality decision, and most harnesses ship one without ever pricing it.
What it does#
Paritok-4B: Intent-Conditioned Context Compression for Coding Agents, by Jiayu Shi and Luzhuo Chen, is a compressor built specifically for coding-agent context rather than for prose. Mechanically it is a rank-32 LoRA on Qwen3-4B-Instruct — deliberately a general-instruct base, not a code model — distilled from a gpt-4.1-mini teacher over 67,074 real OpenHands trajectories. Those get parsed into 469,518 turn-level samples, filtered to real actions, and reduced to 40,606 validated segment-level examples. At inference a gateway classifies each incoming chunk by type (file_read, bash_command, log_output) and assigns an importance level, and the model compresses each segment independently.
Two commitments separate it from general-purpose prompt compressors. First, it is extractive: it selects spans instead of rewriting them, and 96.0% of the identifiers, paths, and numbers it emits already appeared in its input. That matters more than it sounds. Prose-trained compressors paraphrase, and a paraphrased function name is precisely the token the agent needed verbatim for its next exact-match edit. Second, it is intent-conditioned: it is told what the agent is currently trying to do. The empirically interesting wrinkle is how that signal gets used — intent does not change how much context is retained, it changes which lines survive. Retained lines score 0.234 on intent overlap against 0.167 for removed ones, a +0.067 paired difference with a 95% CI of [+0.056, +0.078].
The key result#
On all 300 SWE-bench Lite instances, Paritok-4B compresses agent context to 25.7% of its original size while retaining 86.5% of uncompressed solve quality. That is 2.0x harder compression than a gpt-4.1-mini compressor (50.2%) and 2.4x harder than gpt-5 (61.9%). Fed the cat -n line-numbered input real agents actually emit, it compresses a little less (27.8%) and retains more (89.3%).
But the number that should change someone's architecture is in the cost model. Pricing one turn of 1M context tokens against Claude Sonnet at $3.00/M input: GPT-5 as compressor costs $1.25 to read plus $6.19 to write, $7.44 total, to save $1.14 downstream — $6.30 per million tokens worse than sending the raw context untouched. GPT-4.1-mini nets a thin $0.29 saving. Paritok-4B carries no per-token fee at all, leaves $0.77 of upstream cost, and breaks even so long as self-hosting stays under $2.23/M tokens — on one 24 GB GPU, from a 264 MB adapter.
Why it matters#
Every serious harness now has a compaction step, and almost all of them are implemented the same lazy way: when context gets long, call a good model and ask it to summarize. Claude Code's compaction, OpenHands' condenser, and the summary a sub-agent hands back to its parent are all instances of this. What this paper does is put a price tag on that step and show the tag can exceed the bill it is meant to reduce. The transferable artifact here is not the model — it is the break-even inequality. Your compressor is worth running only when its own input-plus-output cost falls below the upstream tokens it removes, which for a compression rate r means beating (1-r) times your upstream input price. Frontier models lose that inequality on output pricing alone, because a compressor is an unusually output-heavy workload. If you have a compaction step in production and have never done this arithmetic, do it this week; the answer is uncomfortable more often than not.
The second practitioner point is the extractive-versus-abstractive split, and it is a correctness argument rather than a cost one. If your harness does string-match edits — and most do, including the Edit tool pattern — an abstractive summarizer upstream is actively hostile to the tool downstream. It rewrites the exact spans the edit needs to match. Paritok's answer is to make span selection the only operation. Worth noting, though: even here the authors recommend a presence check on identifiers with fallback to the original segment, because roughly 60% of identifier tokens are discarded by design. The 96% figure describes the fidelity of what it emits, not how much it keeps. The intent-conditioning finding is the third thing I would file: passing task context into a summarizer buys you reprioritization, not more shrinkage. If you were expecting a task-aware compressor to compress harder, it does not — it compresses differently.
The caveats#
This is where honesty is required, because the framing is broader than the evaluation.
It is not an agent loop. The eval gives each instance oracle file context, compresses it segment by segment, and asks claude-sonnet-4-5 once for a unified diff. The authors say so plainly: no turns, no re-reads, no exact-match Edit. So the motivating claim — that re-sent context dominates an agent's token bill — is not itself measured here. A companion paper is promised.
The headline stat test is null, not positive. On the line-numbered run, uncompressed resolves 122/300 and compressed 109/300, exact McNemar p=0.079. "Does not significantly reduce solve rate" at n=300 is a failure to detect a 13-instance gap, not evidence there is none.
It under-drops. Drop recall is 0.24 against an always-keep baseline of 0.59, the four-level importance scheme collapses into two usable bands, and deployments cannot currently dial compression per level.
Narrow distribution and real breakage. Trajectories are SWE-bench-style Python repos, so other languages are unbenchmarked. 16 of 300 compressed patches failed to apply versus 5 uncompressed, partly from the model reflowing multi-line signatures onto one line. There is also no head-to-head against LLMLingua-2 — the authors decline it with a defensible argument about incompatible protocols, but it does leave the general-compressor comparison resting on API baselines they ran themselves.
The takeaway#
What I am filing away is the break-even inequality, not the checkpoint. Paritok-4B is a v1 supervised distillation with a known under-dropping problem and an eval that stops short of the agent loop its abstract is about — I would not drop it into a pipeline today. But the cost model generalizes immediately and costs nothing to apply, and "our compaction step is net-negative" is the kind of finding that hides indefinitely because compaction feels obviously virtuous. Concretely, I am doing two things differently: pricing every summarization hop in my agent setups against the tokens it actually removes, and auditing which of them are abstractive on paths that feed exact-match edits. The second one is a correctness bug waiting to happen, and until this paper I had been treating it as a quality nicety.
Paper: arxiv.org/abs/2608.24188 — Jiayu Shi, Luzhuo Chen. Submitted August 25, 2026 (cs.AI, cs.CL, cs.LG, cs.SE). Weights, data, and evaluation scripts released under Apache 2.0.