Context Compaction for Long-Horizon Coding Agents: Repos, Not Percentages

Context compaction for long-horizon coding agents is the lever that decides what a long run costs you.

And it is the one part of the stack where almost nobody publishes a figure you can check.

I went looking for published cost numbers.

Two receipts survived the search.

That count is the story.

The first is an arXiv paper, 2608.06503, which states: "Our code is in https://github.com/nokia-applied-research/Trace." The second is a curated GitHub list of long-horizon agent research that files "Context as a Tool: Context Management for Long-Horizon SWE-Agents" as a 2025 paper.

Everything else was percentages with no workload attached.

Long-Horizon Coding Agents: Two Real Receipts

The arXiv paper does something most efficiency writeups skip: it ships the implementation. "Our code is in https://github.com/nokia-applied-research/Trace." One sentence.

And the claim becomes checkable. You clone the Trace repository, point it at a task that resembles your actual work. And produce the measurement the writeup left out. An identifier like 2608.06503 is not much to look at. A repo attached to it still beats any orphan percentage.

The second receipt is a reading list. Awesome-Long-Horizon-SE-Agents indexes the field. And its shelf order tells you where attention went. "Context as a Tool: Context Management for Long-Horizon SWE-Agents" sits there filed as a 2025 paper. Beside it, quoted exactly as the list has it: "[arXiv 2025] Toward Agentic Software Engineering Beyond Code: Framing Vision, Values, and Vocabulary. Rashina Hoda. 2025.10.22."

When a curated index for software-engineering agents gives that much shelf space to how context gets managed, the hard part has moved. Handling context stopped being plumbing somewhere along the way.

It is the product now.

Run Your Own Context Compaction Test

My guess going in was that summary quality decided everything.

The retries in my own logs point somewhere else: tokens spent recovering what a summary threw away.

I cannot back that with published data, because none exists to cite. That absence is information too. In a field this active, an efficiency claim with no repo and no workload description is marketing copy wearing a methods section.

So run the test yourself. One afternoon, one real task, compaction on and compaction off.

What did your last long run cost per finished task?

If you need a dashboard open to answer, that is the answer.

Four checks, in this order.

Bill per completed task rather than per session, since clients pay for finished work and sessions are free to wander. Finish rate with the switch in both positions, since a token discount that doubles retries trades a saving for a worse rate. What the summary keeps, which should be task state, files touched, and decisions still open. And re-read cost, the tokens spent going back for information that was condensed away. Nobody publishes that last number. It is the true price of the compaction.

Here is the arithmetic, with stand-in figures so you can see the shape. Call the uncompacted run 640,000 input tokens. Call the compacted run 290,000. Looks like a win. Then notice the compacted run needed three attempts where the other needed one, given that the summary dropped an open decision and the agent rebuilt its own plan twice. Multiply before you celebrate. Those figures are invented for the arithmetic and labeled as such; when I run this against the Trace code, the real ones replace them.

One admission: I have not yet run the Trace implementation against a client task. This post is the argument for why I will. And the on/off bill is the number I intend to write down first.

Compaction Methods: Threshold, Retrieval, Memory

Three approaches to compacting a context, and I have opinions on all of them.

Threshold summarization is the default. The window hits a fixed limit, older material gets condensed into a summary, and the run continues. Cheap to implement, fires whether or not it is a good moment. And from that instant the summary is all the agent remembers of its own work. Whatever it dropped is gone unless the agent pays to re-read it. Pro: no infrastructure to build.

Con: the discard is silent, and the loss surfaces later as a retry.

Retrieval keeps the raw material outside the context and pulls pieces back when a step needs them. Decisions survive verbatim, which is the part I care about, since a summary that keeps the prose and loses the decisions leaves you with an agent re-arguing its own plan halfway through.

Con: you pay the re-read on purpose, and the indexing has to be built and debugged.

Hierarchical memory layers it instead of choosing: working notes near the top, durable facts and settled decisions underneath.

Best fit for genuinely long work.

Also the most engineering, and the hardest to inspect when something goes quiet.

If forced to rank them for a small shop, on finish rate alone: retrieval, then hierarchy, then threshold. That ranking is judgment, not measurement.

Context Compaction Questions, Answered

What is context compaction?

When a coding agent's context window fills on a long task, something has to give. Compaction is the deliberate choice of what gets summarized, truncated, or moved out so the run can continue. The alternative is not a clean option: the window fills, and the choice gets made for you.

When should an agent compact context? Before it is forced to, at a point you picked, with content you decided is safe to lose. Fixed thresholds are everywhere as they are simple, not since the threshold moment is ever a good one.

Does compaction hurt finish rate? It can, and the mechanism is dull. The summary drops a decision, the agent rebuilds work it already finished. And the retry burns more tokens than the summary saved.

Which is exactly why finish rate belongs in the on/off test and not in a footnote.

My Small-Shop Verdict on Context Compaction

For a solo operator or a small agency, this is a cash question dressed up as a research question. Model prices sit on a public page and do not move. What the agent keeps and what it forgets is your call, on every build.

A strategy that quietly discards an agent's own decisions costs you twice.

Once in tokens. Once in the deliverable you fix before a client sees it.

The verdict is short. Pull the repo, run one real task with compaction on and off, write both bills down. That comparison beats every percentage with no repository behind it.

And if you want a second pair of eyes on your agent pipeline before it touches client work, that is the work my shop does. Get in touch.

Sources

- arXiv 2608.06503 - Trace repository - Awesome-Long-Horizon-SE-Agents