Surviving the Fold: A Ladder for Long-Running Agent Sessions and Compaction

Mountaineers do not carry an expedition up the mountain; they cache it. A long climb is divided into camps, each stocked with what the next leg requires. Anything not needed stays below, available if the party must return but never hauled higher. What reaches the summit is whatever survived each camp's decision about what to leave behind.

A context window behaves the same way. Capacity is fixed, the route is not, and sooner or later something must be left behind.

Prompt caching already gave one rule for agent harnesses: never invalidate the cache. Keep the stable portion warm and push change to the end. That rule treats a session like a still photograph, though, and sessions have a time dimension. Every session ages. The conversation grows until the window fills and has to be folded.

A fold shrinks the window; that part is mechanical. The price is less obvious, since folding forces the cache to be invalidated. It gets paid once, whatever survives is rewritten, and the session carries on. Still, the invalidation is a side issue. The real matter is the selection of what makes it through. Good compaction is not just deletion: it condenses a history into a form from which the agent can keep going. And a long session does not fold only once. It folds, works, folds again, and sooner or later folds a fold.

That reframes the planning question. Asking when to compact matters less than asking what remains after repeated rounds of folding, and what has been lost by then. Timing is a cost issue, because every invalidation is billed. Compression quality is an identity issue, because it determines whether the session afterwards is still the one that began. For both reasons compaction belongs at the top of the ladder, not the bottom.

Where the bill accumulates

Every request splits into two billing zones. One is the prefix, which survives from turn to turn. The other is the tail, which keeps growing.

The prefix holds the system prompt, tool definitions, stable repository context and rules files. It is written a single time, cached, and later read back for a small fraction of the original price. It stays the same size.

The tail is all that follows: dialogue, tool calls, their results, thinking blocks and diffs. It only expands.

Expansion is not what hurts, though. Repeated charging is. A new message does not travel alone. The harness resends the matching prefix, pays the cached read rate for it, and pays the write premium for the new material, and the entire tail is carried through each of those reads. So 150,000 tokens of tail is not an inert balance sitting in the window; it is billed again on every turn, regardless of whether the model needs any of it for the next question. Old history is effectively leased for the lifetime of the session.

In a 200k window, much of the space is already spoken for. Depending on the harness and several other factors, what is genuinely free for work can shrink to somewhere between 7.5k and roughly 15k tokens.

Caches also expire. Activity refreshes the time-to-live, which means a pause can make the following turn a cold write. Time spent by a human thinking is a hidden cache expense nobody advertises.

Seen this way, compacting the tail is also an operation on the cache. A one-off invalidation charge is exchanged for the end of ongoing rent. That is the whole bargain, and cheaper ways to act exist before taking it.

A ladder of five moves

Five moves exist against tail growth. They are less alternatives than rungs: the higher the climb, the more existing history gets disturbed.

Rung one: never generate it. Cap output at the tool. Anthropic's text editor tool supports max_characters and its web search supports max_uses. Codex limits individual tool outputs to roughly 10,000 to 16,000 tokens by default, before they enter the compaction calculation. A more disciplined variant is snipping: keep the head and the end, cut the middle, on the theory that how a command began and where it finished matter more than the scrollback between. The weakness is truncating before knowing what mattered, and a stack trace missing the relevant frame is worse than none.

Rung two: spill it. If the whole observation is not needed, do not carry it. When a tool result passes a size threshold, the harness writes it to disk and leaves a reference. The full artifact survives while the live context does not. This differs from truncation because nothing is discarded. A 500k-line build log can sit on disk while the context holds only its path, metadata or a searchable index, and a native search or read tool later retrieves just the relevant slice. Keep the artifact, remove the observation. That cleanly separates storage from context, so information stays durable without collecting rent on later turns.

The catch is that the harness must provide the means to find it again. Spilling pays off only when the agent is able to search what it saved, read it and make sense of it; without that, context overflow has been traded for a filesystem of unretrievable things.

The convergence among harnesses is notable. Claude Code writes any tool result larger than about 100k to disk and hands back a preview and a path, and Hermes applies the same 100k cap per result. Both carve out the same exception for the read tool, because a spilled read yields a path the agent would only read again, a read spilling to a path that is read, spilling again, forever. Loops of this sort are easy to fall into. The single tool whose purpose is to bring content back is the one that must never spill.

Rung three: keep it out. Hand the work to a subagent. Equipped with the harness's native tools, it can read files, comb through logs and survey the repository, piling up a large private context, while none of that enters the parent's tail. Once the job is done its window is discarded and only the return value crosses over. Harness vendors made this one of their most widely shipped features this year.

There is a limit, because exploring is safer than changing things. A worker that reads the wrong files merely forces a rerun. A worker that edits the wrong files leaves damage after its context has gone, so it matters which model is trusted with changes. Old armies illustrate it: scouts were quick, expendable people sent ahead, since looking is inexpensive and the report can be checked, while the real decisive action was entrusted to the best commanders because it cannot be reversed. The same split applies here. Give scouting to a cheap, throwaway context, save the strongest model for the step that alters the world, and keep the parent involved in checking. The parent pays for the answer and not for the investigation.

Rung four: swap it for a pointer. If the content is already stored durably, whether as a file, artifact, generated report or spilled result, the conversation needs only a reference to it. Looking again means going to where the material lives, not carrying it around. Anthropic's memory tool does precisely this, and OpenAI supports similar behaviour via function calling. Costly conversational state becomes a cheap reference to durable state. One caveat applies: the savings last only while the underlying content stays outside the window. Once re-read, it is tail again and starts accruing rent immediately.

Rung five: remove it afterwards. Clear, compact or fold. Only this rung invalidates what is already cached. A turn is spent trading accumulated history for something smaller, with the hope that the next turn can proceed from that. The full transcript can remain on disk, yet the live context is different.

From here the economics turn into a bet. Does the rent avoided for the rest of the session exceed what rewriting the history costs now? Compacting early throws away a warm cache that might have served hundreds of cheap turns. Compacting late means rent has been paid on a mountain of history, during which the model may already have become worse at using it. Most talk about long sessions begins at this question, and it should not. The five rungs in order:

1. Never produce it: stop tail growth at the source.
2. Spill it: take the bulky observation out and keep the artifact.
3. Keep it out: send the investigation to a different context.
4. Point to it: leave a cheap reference in the conversation.
5. Delete it later: compact or fold, and live with the loss.

The cheapest context is not compressed context. It is context that never had to be there.

Tool sets as a bet on where to pay

Where a tool definition sits matters. Definitions occupy the prefix, a fixed charge that is written once and cached. Results occupy the tail, a variable charge that keeps being paid. Choosing a tool set is therefore a wager about which zone should absorb the cost of information. Few tools mean a small prefix but more raw observation in the tail; many tools mean extra prefix tokens spent in order to receive smaller, more structured observations.

Terminus 2 is the lean extreme: one headless terminal, built on the Unix conviction that one general tool can be composed without limit. Codex often gets grouped with it, which is only partly fair. Its native prefix is hardly tiny, with about 20 permanently present tools, a multi-agent suite and a v1/v2 pairing. It avoids bloat through deferral, indexing MCP and connector tools in a search engine and loading them when needed. Codex really places its minimal bet in the tail. apply_patch illustrates this, since a short diff stands in for thousands of tokens of rewritten file, and caps on each tool's output keep raw observation from accumulating. The two end up in similar places by different routes: Terminus 2 keeps the prefix small, Codex keeps the tail small.

Claude Code and Hermes spend more prefix on specialised tools that return structured observations instead of raw ones. Claude Code's catalogue passes 40 once LSP, plan mode, worktrees and cron are counted, and Hermes reaches about 55, grouped into toolsets for terminal, files, memory, skills, delegation and more. Grep returning matches rather than a whole file is the pattern: a little more permanent prefix to avoid thousands of tokens of permanent tail.

So the comparison to make is not about tool counts. It is whether extra prefix spending removes enough tail growth to put off the fold. This is the same eager versus just-in-time tradeoff, applied a level higher. Anthropic's deferred loading states it plainly: tool definitions can be discovered when required rather than included on every request. Claude Code does this with a ToolSearch mechanism that leaves the names of deferred tools visible and withholds full schemas until the model asks, turning on by itself when MCP tool definitions pass about 10% of the context window. Even ordering is chosen to protect the prefix, since alphabetical sorting keeps the definition block byte-identical between turns and therefore cacheable. The prefix is designed to remain warm, regardless of its size.

The axis keeps its usefulness, but its role shifts. It does not decide whether to compact. It decides how much history piles up first. And that history is not homogeneous. Search results are often re-derivable, decisions are not. A file path can be reconstructed, while the reason an approach was rejected may not. The longer a session runs, the costlier it becomes to confuse those two kinds of memory.

Delegation as a memory boundary

Delegation stands out as the rung that sheds history while leaving the parent's cache untouched, and that is worth more than a discount on running work. A subagent has its own context window. It may grow an enormous tail, fill the window, compact internally and then vanish, all without rewriting a word of the parent's history.

A common assumption needs adjusting. It is attractive to imagine same-model forking, in which a child inherits the parent's accumulated tail along with its warm prefix. The implementations that can be checked mostly do not do this. Claude Code, OpenCode, Codex and Hermes each start separate worker contexts, not a copy of the parent's whole tail. Several can put the worker on a different model, with Codex taking a model override at spawn time and Claude Code letting each subagent choose sonnet, opus or haiku. That is not universal, and Hermes' delegate has no direct way to switch models. What carries across harnesses is the separate context, not the model choice.

This points to something bigger than forking. The child's tail can be thrown away: it may read forty files, scan logs and map out a naming convention, and the whole context disappears while a paragraph comes back. Delegation acts as a memory boundary. The parent assigns a task and says what it needs, which amounts to compression done in advance, because the worker knows who will read its output and which decision the output must support. When a subagent returns, the parent normally checks the result. Doing so uses a few turns and is wise.

Compaction runs the other way around, after the fact. It has to summarise for a reader who does not yet exist, hedging against any question that might come next. Compression in advance has the benefit of a known reader. This yields a budgeting principle: budget for what comes back, not for the run. A worker can spend hundreds of thousands of tokens without any of them becoming parent memory. The returned text does become memory. Four hundred tokens of answer land in the parent's tail and are billed on every later turn, so across a long session a raw diff can cost more than an expensive worker that returns a single useful sentence. The investigation is temporary and the answer is history, and that answer will in turn have to survive a fold.

What the platforms provide

The model platform determines how much of this machinery the harness must build itself.

Anthropic offers two kinds of help aimed at different problems. The first, clear_tool_uses_20250919, is precise. When the prompt passes a threshold (100k input tokens by default, with the three latest tool uses retained) it clears old tool results on the server and puts a placeholder in each place. Its clear_at_least option spreads the invalidation cost by requiring a minimum amount cleared. The second, compact_20260112, is the heavy tool: full server-side summarisation that produces a new version of the conversation, not a cut into the existing one.

Claude Code is a good case study, since even the harness made by the company that ships these primitives seems to coordinate its heavier /compact on its own side. Support for this comes from community reverse-engineering that traces back to a single exposed GitHub source, not from Anthropic's public documentation. Light clearing happens on the server, while the step that decides which conversational state survives is orchestrated by the client.

OpenAI concentrates on compaction. Its /v1/responses/compact endpoint returns an encrypted opaque blob that the client hands back without looking inside, partly to shut a prompt-injection route in which a tampered summary could steer later turns. Nothing there corresponds to surgical clearing, so Codex has to handle tool-output size itself, and beneath both paths is a blunt fallback: if the window overflows regardless, Codex discards the oldest history item and tries again.

DeepSeek supplies much less in the way of context management. Its server-side prefix caching lowers cost but does not solve the fixed-window problem, so any harness there owns the full compression pipeline. The official DeepSeek harness builds one and does so without destroying anything: shadowed events remain in the log and can be reached. One third-party terminal interface that was checked skips the work and never compacts proactively.

What matters is not the quality of any one API's compaction endpoint but who is responsible for deciding what survives. Hermes is a revealing limit case because it spans several providers and cannot assume any of them offers the right primitives. It therefore runs its own client-side compressor as a baseline, using two thresholds: 50% according to its own token accounting, and 85% from a coarser gateway-level check that catches sessions that grow between turns while no one is watching. Whenever the active provider has something better, it defers.

That is the sound general design. The harness should own compression by default because it has information a server may never see, and hand off to the platform when the platform has earned it. Whoever performs the fold, the question stays the same: what is acceptable to forget?

Coming back to camp

All of the above assumed the session never stops. Sessions do stop. Laptops close, processes die, CI jobs exit, and someone types /resume expecting to pick up where things left off.

It is the easiest command of the day for the most expensive turn of the session. It is seven characters including the slash, shaped like /help or /clear, with no arguments, no confirmation and no friction. Nothing in it signals its price, and the interface is tuned so that coming back feels free.

The conversation can be restored, but the cache cannot. A resumed session is not a process that was paused. The harness replays the transcript from disk and rebuilds the message history, so the dialogue comes back from storage while the warm prefix does not. Two different recovery costs follow.

The first is money. Anthropic's prefix cache lives five minutes by default, or an hour if the larger write was purchased, and only activity refreshes it. A resume is idle time pushed to its extreme, a gap in which no process exists at all. The prefix that used to be cheap returns stone cold and the following turn pays the full price to rebuild it. The most expensive case is picking up a session that ran for days, which is a good reason to manage sessions with some care.

The second is information. When the transcript is bigger than the available window, the harness might need to fold it before any new action happens. That is an especially risky fold, since compression occurs before anyone has re-established what matters. A constraint that explained a choice nine turns back may be present in the transcript but absent from the compressed version. The agent resumes with a smaller window and a believable history, not necessarily the history that made the earlier decisions sensible.

Whatever survives a fold also survives a resume, and that is the deeper case for durable state. Project-root rules can be injected again from disk, files can be reread, a to-do list rebuilt, and a generated build log stored and referenced. A decision that exists only in the conversation has no outside source. If it lasted only because the transcript carried it, it has to be paid for again on return, and if the fold removed it, it may be gone for good.

So the ranking concerns durability as well as price. From sturdiest to most fragile: state that can be reconstructed, durable external state, live conversational state, then transient observations. The lower an item sits, the more exposed it is to a fold.

Two ways folding fails

Folding fails in two ways. The sharp one is easy to spot. Compaction works, then a huge tool output refills the window immediately, the harness compacts again, the same output returns, and the cycle repeats, like bailing out a boat while drilling a hole in it. Claude Code gives up retrying instead of burning calls in a loop, with built-in logic to detect that it is stuck and not progressing. That is the correct behaviour, but the loop is itself a signal that the wrong rung is in use. Ideally the agent steps back and tries another approach rather than retrying the same native tool. If a single oversized file keeps forcing compaction, a lower threshold is not the cure. Reading a narrow range of lines, grepping within a limited scope, pointing at durable output, or handing the file to a subagent whose window is expendable would be. Whenever compaction tuning starts, ask whether the fix lies three rungs higher or in a different approach altogether.

The slow failure is more subtle. Compaction loses information, and long sessions never compact just once. They compact, work, compact, work, compact again: summaries stacked on summaries.

Folds of folds

A first fold may be excellent and still lead to a poor third one. The second summariser never sees the original history, only the first summariser's chosen representation. The third sees neither, only the second's verdict on the first's verdict. Look at what that does to facts versus reasons. The first fold could keep "approach B was chosen." The second could keep "B is the current implementation." The third could keep "the implementation uses B." Each is true, but why approach A was rejected has disappeared. The system has not lost the decision. It has lost what made the decision understandable, and that is the particular damage done by folds of folds.

What should survive

Across harnesses, structured summaries converge on roughly the same categories:

• Intention: what is being accomplished?
• State: what has been learned or changed?
• Work and to-dos: what is done and what remains?
• Open items: which questions are still unsettled, restricted or being weighed?

The labels vary between harnesses, but the structure recurs, which suggests it is close to the smallest practical state a session must preserve. Several harnesses also add file-restoration steps so the working set can be reloaded after a fold.