AgentZip compresses agent sandboxes 8.7× — Cross-sandbox memory redundancy — What does it mean?
The news. On September 10, 2026, a paper posted to arXiv described AgentZip, a memory system for high-fanout agent sandboxes. Rather than treating each sandbox as an independent program, it looks for profitable representations using template-relative redundancy (how a page differs from the base image) and cross-sandbox redundancy (how a page differs from a sibling's). The authors report sandbox-owned memory reduced by up to 8.7×, against 2.1× for the Linux configuration they compare against. Read the paper →
Imagine two hundred copies of the same two-page form, each filled in by a different person, and a filing clerk told to save space. The clerk's instinct is to take each copy and shrink it — smaller print, thinner paper, one sheet instead of two. Two hundred copies become one hundred copies' worth of cabinet, and everybody calls it a good day's work.
The clerk has missed the obvious thing. Nearly every mark on those two hundred sheets is pre-printed text that was identical before anyone picked up a pen. File one blank master and, for each person, only how their sheet differs from it, and the cabinet empties out — not because the paper got thinner but because the clerk finally noticed what the copies had in common.
An agent fan-out is that cabinet. Each sandbox boots from the same template: the same base file system, the same libraries, the same interpreter sitting in memory. A stock Linux configuration is the first clerk — Linux compresses each process's cold pages against nothing but themselves, the way zswap and zram do, and the paper reports that configuration reaching about 2.1×. AgentZip is the second clerk: it compares each page against the template it came from and against the siblings running beside it, and reports up to 8.7×.
And then there is the handwriting that repeats. Sibling agents on one task do not wander off in different directions; they run related trajectories — reading the same repository, importing the same modules, hitting the same endpoints. So the pages that have diverged from the template often have not diverged far from each other, and each can be stored as a small difference against a sibling rather than in full. That is the second half of the phrase cross-sandbox redundancy, and the part the filing clerk finds last.
It is fair to ask what the kernel was already doing about this, because it does have an answer: copy-on-write. When a sandbox is cloned, the child shares the parent's pages outright until one of them writes, which is genuinely free deduplication. The problem is that copy-on-write only ever gives up ground, and an agent's whole job is to start changing things — every page the sandbox writes when it installs a package or edits a file goes private and is never reconciled again, however similar it stays to its sibling's copy. Template-relative comparison picks up exactly where copy-on-write drops out.
| What each page is compared against | Reported compression | Source |
|---|---|---|
| Nothing — stored uncompressed | 1.0× by definition | — |
| Identical pages at clone time (copy-on-write, kernel default) | not measured here; untouched pages stay shared, each written page goes private | — |
| Only itself, per process (Linux configuration) | ~2.1× | paper |
| The shared template plus sibling sandboxes (AgentZip) | up to ~8.7× | paper |
Hold two numbers fixed and the gap becomes a hardware decision. Say a fan-out spawns 200 sandboxes and each holds 1 GB resident (both illustrative; the ratios are the paper's), so the raw bill is 200 GB. Per-process compression at the reported 2.1× brings that to ~95 GB. Comparing against the template and the siblings at the reported 8.7× brings it to ~23 GB. The ~72 GB between them is the difference between a fan-out that needs two 64 GB hosts and one that fits on a single host with room to spare.
If the shape of this argument feels familiar, it should: it is the same move the serving layer already makes one layer up. Many requests that share a long system prompt do not each need their own copy of its keys and values, which is why the shared-prefix waste is worth a whole caching scheme. AgentZip is that idea pushed down from tokens to operating-system pages, and it lands on the same practical question: what does it actually cost to run a team of agents instead of one, once you count the things that are not tokens? The answer partly depends on why you fanned out at all — isolating context in subagents buys clean context windows, and this is one of the bills that arrives for it.
Goes deeper in: Agent Engineering → Agent Teams → Coordination Costs
Related explainers
- AgentZip compresses agent sandboxes 8.7× — LLM-wait latency hiding — the other half of the same paper: when to run the compression, so that squeezing this hard does not slow the agent down.