What compaction is

A coding agent does not have a roomy inner life. It has a context window: one request that grows with every instruction, every reply, every file it opens, every command it runs. The model can only see what still fits. When the next turn would overflow, there are two honest options. Start empty and lose the thread, or write a smaller representation of the thread and keep going.

That smaller representation is compaction. It is a prefix summarizer. The newest stretch of the session stays as it happened. Everything older is replaced by one recap. The raw prefix is gone after that.

Compaction is not starting over. Starting over is a new conversation. Compacting continues this one, with a shorter account of how it got here. Compaction is also not memory. A recap is a handoff into the next request. A fact that still has to be true next week belongs somewhere that outlives the window.

Principles

Five constraints shape a compaction that an agent can keep working with.

Keep the recent work verbatim. The last stretch of the session is where the live bug, the open file, and the last failing test still sit in the model's own words. Summarizing that tail is how an agent forgets what it was doing.

Cut by how much room the history takes, not by how many turns it contains. One file body can outweigh ten exchanges. Dropping the oldest twenty messages will either keep too much trash or throw away the one payload that still matters.

Never split an action from its outcome. A result without the request that produced it is not a conversation the model can legally continue. The cut sits between complete turns, not through the middle of one.

Make the recap structured and literal. Unstructured prose is hard to check and easy to paraphrase into mush. A recap that names the goal, the progress, the blockers, and the next steps can be read, tested, and updated. Filenames, paths, numbers, identifiers, and other short literals should be quoted, not restated.

Treat the recap as lossy. If a fact is not written somewhere else before the flush, it is gone. That is not a defect in the summarizer. It is the cost of fitting.

Why it matters

The context window is the working memory of the turn. Overflow is not a warning. The model host rejects the request, and the turn fails. A session that cannot compact cannot continue once the work has been long enough to matter.

Filling the window is also a quality problem, not merely a length problem. Across coding harnesses, people report that answers get worse well before the hard limit, often while utilization is still a minority of the advertised window. The exact fraction is contested. The direction is not. An agent that carries every raw file body from two hours ago is paying for noise, and then paying again in worse answers.

There is a cache cost. Prompt caching needs an exact prefix. Compaction rewrites that prefix, so the older history cannot be reused on the next request. An overflowed window is still worse than a cold prefix. Requests after the cut start caching again.

For a coding agent the loss is concrete. A path that was read, a test that failed, a decision the user already made: if those live only in the discarded turns, the next request rediscovers them or contradicts them. That is why compaction never stands alone. Lasting notes are the side channel that can survive the flush. Undo cannot walk back through a compact, because the original turns are no longer there to restore.

How it works

The mechanism is the same in outline wherever compaction has settled as the default.

Watch how full the window is getting. When it is too full, keep a recent stretch intact and send everything older to a summarizer. Replace that older stretch with the recap. Continue.

Two moments matter, and they should not share a failure policy. Compact while there is still room, because the window is getting tight. Compact again if the host still refused the request as too long, and retry that same call. If an early compact fails, the original history still fits, and work can continue. If a compact after overflow fails, nothing that fits is left, and the turn is over.

A recap that already exists should be updated, not rewritten from scratch. Finished work moves into progress. Blockers the new turns resolved are dropped. Concrete literals from the previous recap are kept.

The summarizer should not be handed giant file bodies. Elide them to a size marker, and tell the model not to invent the missing contents. Which files were read, and which were changed, can be recovered from the work itself. Asking the summarizer to remember the paths is how they get paraphrased away.

How seri does it

seri treats compaction as part of continuing the session, not as a separate product.

It uses the same model that is already doing the work. A cheaper summarizer would save money and lose the literals the next turn still needs. The recap has four jobs: what the session is trying to do, what has already been done, what is still in the way, and what comes next. Progress, especially, should quote the concrete bits (a path written, a value returned, a name that still binds) rather than describe the action in the abstract.

If a recap is already sitting at the front of the session, seri updates it. Completed work is promoted. Stale blockers fall out. The alternative, rewriting the whole story each time, is how early decisions get sanded into generality.

Files are not left to the summarizer's memory. The recap lists what was read and what was changed, taken from the work that is being thrown away. A file that was both is listed as changed. The next turn then knows the map of the session without having to reopen every path.

seri will compact on its own as the window fills, and it will compact again if the host still says the request is too long. You can also ask for a compact in the middle of a session, and you can tell it what to protect. An early compact that fails does not stop the turn. A compact that was the last chance does.

After a compact, the original turns are gone. Undo will not walk through that point. The session still has whatever was recorded since the recap. Everything older lives only as the recap says it does.

The field has not settled on when to compact. Some harnesses wait until the window is almost full. Some cut much earlier, on the observation that quality falls off long before the hard limit. seri makes the threshold a choice rather than a finding. We do not yet have a measured, model-aware eviction policy. Nobody we have looked at does.

The recap is not the memory

Compaction is lossy on purpose. Lasting notes are the side channel that can survive it. A save that runs as the window approaches a compact is worth more than the same save on an arbitrary clock: the point is that the fact outruns the flush.

Those notes land on disk, after you approve them, and a later session can start already knowing them. Compaction can forget the raw turns. The next session can still start knowing the fact. What nobody thought to save still does not survive. That is the remaining loss, and it is not a summarizer bug.