Memory Compression for High-Fanout Agent Sandboxes Mengming Li∗
Ceyu Xu∗
Qijun Zhang
[email protected] HKUST
[email protected] HKUST
[email protected] HKUST
Jiangnan Yu
Xiangfeng Sun
Haohui Mai
[email protected] HKUST
[email protected] HKUST
[email protected] HKUST
arXiv:2609.11294v1 [cs.AI] 10 Sep 2026
Zhiyao Xie† [email protected] HKUST
Abstract High-fanout agent workloads create a growing memory bottleneck because a single task may spawn many concurrent sandbox sessions. Yet these sandboxes are far from independent: they originate from a shared template and execute related trajectories, exposing substantial template-relative and cross-sandbox memory redundancy. Conventional memory compression is poorly matched to this setting in three fundamental dimensions: how to compress, because they fail to exploit similarity across non-identical sandbox pages; what to compress, because they control page-fault overhead through conservative page selection; and when to compress, because compression is either triggered by memory pressure or performed without awareness of agent execution phases. We present AgentZip, the first memory compression system designed specifically for AI-agent sandboxes. AgentZip introduces compression mechanisms that exploit both the template-relative and cross-sandbox redundancy. It broadens the compression scope to any page with a profitable representation and shifts overhead control from compressiontime page selection to restore-time prefetching. It further aligns expensive compression with LLM waiting periods to avoid interfering with foreground tool execution. Across LLM training and inference workloads, AgentZip reduces sandbox-owned memory by up to 8.7×, compared with 2.1× for the Linux configuration. Restore prefetching and agentexecution-aware scheduling reduce the slowdown of aggressive compression from as high as 3.1× to 1.40× while retaining nearly all of its memory-saving benefit.
1
Introduction
Modern AI agents no longer merely produce text. To resolve a software issue, analyze a dataset, or operate a computer, an agent typically issues shell commands, edits files, installs dependencies, and runs tests [7, 22, 26]. Because these actions execute untrusted code and mutate persistent state, agent ∗ Mengming Li and Ceyu Xu contributed equally to this work. † Corresponding author.
One Task / User Request e.g., “Analyze repo and fix bugs”
Template-relative Similarity Template Sandbox 1 Clone Base OS, libraries, Copy-on-Write config, tools…
LLM Training (Rollout) Same Prompt, Different Temp
S1
S2
…… Sn
Evaluator / Reward Model
Private State
Sandbox 2 Private State
Cross-sandbox Similarity
Similar files & Dataset
Private State
LLM Inference （Generate-and-Filter) Same Task
Similar commands & System calls Similar libraries & System calls
Sandbox N
…
Different Idea
S1
S2
…… Sn
Filter / Best Idea
Figure 1. Similarity between sandboxes creates opportunities for inter-sandbox memory compression. platforms nowadays choose to run every action inside a sandboxed execution environment that provides isolation and lifecycle control [2, 27]. As a result, the agent sandbox is no longer a peripheral part of the serving stack: it is where agent execution actually happens. Memory as bottleneck due to scaling. Agentic workloads are increasingly high-fanout: a single task spawns many sandboxes rather than one. As shown in Figure 1, during reinforcement learning (RL) training, an agent samples tens of independent trajectories per task so that an RL reward model can score them [21, 29]. During inference, multi-agent workflows run several candidate sessions concurrently to speed up parallel trial-and-errors [18]. In summary, fanout enables productive LLM training and inference, but it also makes them expensive. Specifically, it changes the unit of provisioning: a host no longer backs one sandbox per task, but tens of concurrent sibling sandboxes. Crucially, the resource that usually runs out first is memory instead of compute. Sandboxes spend much of their life blocked on model output: between two tool calls, a sandbox sits idle waiting for the
is poorly matched to reducing the average sandbox memory footprint over its lifetime, because compressible pages may remain resident for most of a session. This paper presents AgentZip, a sandbox memory compression system that rethinks these three fundamental design choices for high-fanout agent workloads. [How]: Sandbox-aware redundancy model. AgentZip directly exploits the two forms of memory redundancy exposed by sandboxes. 1) For template-relative similarity, it represents a sandbox’s private page as a compact delta from its corresponding immutable template page. 2) For crosssandbox similarity, it builds shared dictionaries that capture common byte patterns across sibling sandboxes and uses these dictionaries to encode candidate pages. These mechanisms broaden the exploitable inter-page redundancy beyond exact page equality. AgentZip further combines them with lightweight intra-page compression and selects the most space-efficient representation for each page. [What]: Unlimited compression scope. AgentZip no longer restricts compression eligibility based on page hotness or predicted reuse. Instead, any page is eligible for compression as long as it can be compressed profitably, including warm pages that are likely to be accessed again. This broader scope is enabled by a new compression paradigm: Instead of avoiding future page faults through selection at compression time, AgentZip allows compressing warm pages by mitigating page faults at page restore time through prefetching. At restore time, AgentZip predicts which compressed pages will be needed soon and prefetches them before demand. [When]: Agent-execution-aware compression timing. Rather than waiting until memory pressure to start compression, AgentZip proactively aligns compression with the agent execution lifecycle: it performs lightweight candidate discovery during tool execution and moves expensive compression into LLM waiting periods. This lifecycle awareness avoids interfering with foreground tool execution while reducing the time-averaged sandbox memory footprint. The contributions of this paper are summarized below: • We present AgentZip, the first memory compression system that exploit the redundancy within AI-Agent sandboxes. We identify sandbox memory as a firstorder scaling bottleneck in high-fanout agent workloads and show that sandbox-specific redundancy and execution structure create substantial opportunities beyond conventional memory compression. • We design a sandbox-aware compression algorithm that exploits both template-relative and cross-sandbox redundancy, with lightweight local compression. By capturing redundancy that existing mechanisms miss, AgentZip reduces sandbox-owned memory by up to 8.7× and four times more than Linux configuration. • We rethink how compression overhead is controlled. AgentZip decouples compression from future page faults by aggressively compressing profitable pages
LLM to decode the next command, so cores stay available while memory does not. Opportunity: Redundancy in Memory. If each sandbox occupies 𝑀𝑠 bytes and a host devotes altogether 𝑀ℎ bytes to sandboxes, concurrency is capped near 𝑀ℎ /𝑀𝑠 . However, this linear scaling is far worse than the workload deserves. Sibling sandboxes that fan out from one task are not independent: they are cloned from the same template image, open the same repository, import the same libraries, and run overlapping command sequences. Their memory redundancy comes from two complementary sources: 1) Template-relative similarity. It arises because sandboxes are cloned from a shared template, and many private pages remain close to their corresponding template pages after copy-on-write. However, this similarity can weaken as execution progresses and sandboxes accumulate more private states. 2) Cross-sandbox similarity. It provides a complementary source of redundancy: sibling sandboxes executing related trajectories often develop similar runtime states even after they have diverged from the original template. Section 6.5 shows both forms of similarity are substantial, with 76–96% of pages exhibiting templaterelative or cross-sandbox redundancy in our measurements. At a high level, a memory compression system must answer three fundamental questions: 1) How to compress, which determines which compression algorithms and representations are used to exploit available redundancy. 2) What to compress, which determines which memory pages are selected as candidates for compression. 3) When to compress, which determines when compression is performed and physical pages are reclaimed. We point out that all these three fundamental decisions in today’s mainstream memory compression mechanisms are poorly matched to high-fanout agent sandboxes, as we elaborate below: 1 [How]: Wrong redundancy model. General-purpose compressors such as zswap [1, 4] and zram [16] only exploit intra-page redundancy. These general compressors compress each page independently and therefore cannot exploit its similarity to the original template or to runtime content in sibling sandboxes. Page-level deduplication such as KSM [14] exploits inter-page redundancy, but requires exact page equality. Most of such exact-sharing opportunities have already been covered by copy-on-write at sandbox creation. 2 [What]: Wrong compression scope. Existing compression systems [9, 11, 20] restrict compression primarily to pages unlikely to be accessed in the near future, using access hotness or predicted reuse to control page-fault overhead. This creates an inherent trade-off: compressing warmer pages exposes greater memory-saving opportunities, but also increases costly page faults. Accurately identifying which warm pages can be compressed is difficult. Thus, conservative selection becomes inevitable, leaving many profitable compression opportunities wasted. 3 [When]: Wrong timing. Zswap [1, 4] operates only reactively on the swap-out path and under memory pressure. This compression timing 2
and predicting their restores before demand, while aligning expensive compression with repeated LLM waiting periods rather than memory pressure. These techniques reduce the slowdown of aggressive compression from 3.1× to 1.40× while retaining nearly all of its memory-saving benefit.
2
Background
2.1
Memory Compression
the page must be restored before execution can continue. Existing memory compression systems commonly control this overhead through page selection, deciding which pages are safe to compress based on their expected future accesses. Prior systems [9, 11, 20] typically formulate this as cold-page identification and prioritize pages that are unlikely to be accessed in the near future. However, prior studies show that only about 20–30% of memory pages are cold, while another 50–60% are warm (i.e., not continuously accessed but still likely to be revisited after a moderate interval [9]). Limitations. Existing hotness-based policies will severely limit the full exploitation of inter-sandbox redundancy. Even with perfect cold-page identification, a cold-only policy leaves many potentially compressible warm pages untouched. Expanding compression to warm pages exposes more memorysaving opportunities, but also increases page-restore overhead. Prior study [9] reports that extending compression from cold to cold-plus-warm pages increases memory saving from 11% to 32%, while slowdown significantly rises from 9.5% to 20%. This trade-off makes it difficult for selectionbased policies to aggressively expand the compression scope.
Memory compression increases effective memory capacity by replacing resident pages with smaller compressed representations stored in a memory pool. After a page is compressed, its original physical frame can be released, and only the compressed representation remains in memory. If the application accesses this page again, the system must first retrieve and decompress it from the compression pool and restore the original page before execution can continue. Therefore, memory compression essentially trades restore overhead for memory capacity. The effectiveness of a memory compression scheme is jointly determined by 3 main factors: compression redundancy model, scope, and timing. 2.2
Compression Redundancy Model
2.4
Existing Linux memory-saving mechanisms exploit redundancy using two representative approaches: page deduplication and page-local compression. Kernel Samepage Merging (KSM) [14] is a mature Linux deduplication mechanism originally developed for KVM virtualization. A background kernel thread scans anonymous pages and replaces pages with identical contents by a single write-protected physical page. Subsequent writes trigger copy-on-write and create a private copy. KSM therefore exploits inter-page redundancy, but requires exact page equality. Zswap [1, 4] takes a different approach. When Linux swaps out an anonymous page, zswap compresses the page and stores its compressed representation in a memory-resident pool instead of immediately writing it to the backing swap device. The original physical frame can then be reclaimed. If the page is accessed again while its compressed copy remains in the pool, zswap retrieves and decompresses it during swapin. Zswap supports compressors such as Zstd, LZ4, and LZO, to exploit byte-level redundancy within each page. Limitations. KSM captures inter-page redundancy only when two pages are exactly identical, while much of this exact sharing is already provided by copy-on-write at sandbox creation. Zswap compresses each page independently and exploits intra-page redundancy. Neither mechanism can capture the inter-page approximate similarity between a private page and its template or among pages in sibling sandboxes. 2.3
Compression Timing
Memory compression systems must also decide when compression should be performed. Many OS-level compressedmemory systems, such as zswap [1, 4], operate reactively: compression occurs only after memory reclaim selects a page for eviction and sends it down the swap-out path. This design integrates naturally with existing memory reclamation, but compression begins only when memory pressure exposes pages to reclaim. More recent systems [10, 23] instead perform compression proactively, identifying and compressing candidate pages before they would otherwise be evicted. Limitations. Neither reactive nor generic proactive timing is suitable for agent sandboxes. Reactive compression can act too late for reducing the time-averaged sandbox memory footprint, because compressible pages may remain resident for most of a session before memory pressure occurs. Generic proactive compression exposes more opportunities, but it is unaware of the sandbox execution lifecycle and may perform expensive compression while a tool call is running, directly interfering with foreground execution. Agent sandboxes therefore require compression timing that is both proactive and coordinated with their execution phases.
3
Overview
Figure 2 shows AgentZip’s high-level workflow. It consists of three main components. First, the compression algorithm exploits sandbox-aware redundancy using a portfolio of cohortaware, template-aware, and local compression methods. Second, the compression scheduler decides when compression should run. Third, the restore prefetcher learns page restore
Compression Scope
Memory compression can introduce significant performance overhead when a compressed page is accessed again, because 3
Sandbox Creation Immutable Template
1. Memory State in a Sandbox
…
Local Compression (Low-entropy pages)
Shared Memory (from Template)
…
Page Access (read / write)
Cohort-aware Compression (Inter-sandbox similarity)
Private Dirty (COW / runtime)
Template-aware Compression (Delta to template)
Sandboxes
3. Restore Path
2. Agent Compression
userfaultfd Trap
Compressed Page Store
Page Decode
(metadata + Compressed data)
Map Page Back to Sandbox Resume
Control Prefetch
4. Lifecycle-Aware Compression Scheduler Tool-time Discovery (Scout pages)
LLM-time Compression (Compress pages)
5. Prefetch Engine (Instead of Page Selection) Predict Next Accesses (Stride + Temporal + Hotset)
Cooperative Stop (Avoid inference)
Prefetch Restore (Background restore before demand)
Figure 2. AgentZip overview. AgentZip compresses sandbox-private pages using a portfolio of codecs, schedules expensive compression during LLM waiting periods, and proactively restores predicted pages before demand. Local lightweight compression. This handles pages whose redundancy mainly exists within the page itself rather than across cohort or template sandboxes. For example, pages with repeated bytes or simple low-entropy patterns can be encoded efficiently by a local codec.
patterns and asynchronously restores likely-needed compressed pages before they trigger future demand page faults. 3.1
Sandbox Model
AgentZip works based on a copy-on-write template model for AI-agent sandboxes [28]. In this model, sandboxes are created by forking or cloning from an immutable template that contains the base operating system state, runtime libraries, package environments, and pre-installed dependencies. Initially, sandbox pages can be shared with the template. When the guest modifies a shared page, copy-on-write creates a private sandbox-owned page. This model is common in agentic sandbox deployments because it enables fast sandbox creation and reduces the cost of storing identical initial states. 3.2
3.3
Restore Prefetch Instead of Page Selection
Traditional memory compression systems rely on page selection to control performance overhead. They try to identify cold pages and avoid compressing hot pages. This reduces the chance of future page faults, but it also limits memory savings. In AI-agent sandboxes, this policy is too conservative. Many warm pages may still be highly similar to the template or to pages from other sandboxes. If AgentZip only compresses pages that are predicted to be cold, it would leave much of the sandbox-specific redundancy unused. AgentZip therefore replaces traditional hotness-based page selection with prefetch-guided restore. The key idea is to decouple two decisions. The compression path asks whether a page has a profitable compressed representation. The restore path asks whether a compressed page is likely to be needed soon. This shifts the main performance-control mechanism from compression-time filtering to restore-time prediction, allowing AgentZip to compress more aggressively. AgentZip draws inspiration from CPU prefetching [3, 8, 12, 13, 17, 24] and adapts them to predict compressed page restores in agent sandboxes. It uses multiple predictors to capture complementary restore patterns. A stride prefetcher captures regular sequential restore patterns. A temporal prefetcher captures page-to-page restore correlations, such as which page is likely to be restored after the current restored page. A request hotset prefetcher identifies pages that are frequently restored at the beginning of a tool-execution.
Sandbox-Aware Compression Algorithm
Conventional memory compression systems typically compress pages in isolation, ignoring the structural redundancy exposed by AI-agent sandboxes. AgentZip instead designs sandbox-aware compression algorithms that explicitly exploit both template-relative and cross-sandbox similarity. Cohort-aware dictionary compression. It captures intersandbox similarity by organizing related sandboxes into a cohort. AgentZip samples runtime pages from sandboxes in the same cohort and uses them to construct a shared immutable dictionary that captures common byte patterns. AgentZip uses this dictionary to encode candidate pages. Template-aware compression. This method is designed to capture template-to-sandbox similarity. Since sandboxes are created from a copy-on-write template, many private pages are dirty but still close to their corresponding template pages. AgentZip encodes them as deltas from the immutable template page at the same virtual page index. 4
Sandbox (guest)
4.2
virtual address range, 4 KiB pages
candidate page
resident-private page
reclaimed page
AgentZip’s compression has two stages. First, it provides a portfolio of three codecs that exploit complementary forms of redundancy in sandbox memory. Second, it evaluates the available codecs for each candidate page and selects the most space-efficient representation for final compression.
··· …4000
…5000
…6000
…7000
…8000
guest access
…9000
VPN
2
userfaultfd (kernel) forwards faults to user space; it never compresses pages page-fault event 3
compress page, store the entry, 1 free 4 KiB frame
4
4.2.1 Cohort Dictionary Compression. Cohort dictionary compression captures redundancy across sibling sandboxes. AgentZip assigns each sandbox a cohort identifier as cohort_id = Hash(template_id, request_id). The template_id ensures that sandboxes in the same cohort share an identical base environment. The request_id groups sibling sandboxes created for the same agent task. Such sandboxes commonly execute similar commands, access similar files, and construct similar runtime states. Dictionary Training. AgentZip samples resident-private pages from sandboxes in the same cohort and trains immutable Zstd dictionaries. The dictionary stores byte patterns that commonly appear in sandboxes within the cohort. Once a cohort has accumulated a sufficient number of samples, AgentZip initiates a new training round and partitions the sampled pages into a training set T and a validation set V. AgentZip uses T to construct the candidate dictionary. It then evaluates each page on V by measuring the net memory saving, including both compressed sizes of the validation pages and storage cost of the dictionary itself. AgentZip publishes a candidate dictionary 𝐷 ∗ only if it provides sufficient memory saving on V and fits within the global dictionary budget. Specifically, 𝐷 ∗ must satisfy Saving(𝐷 ∗, V) ≥ 𝜃 dict and 𝑀dict + 𝑀current ≤ 𝜃 total , where 𝑀dict is the size of 𝐷 ∗ , 𝑀current is the memory occupied by all currently published dictionaries, and 𝜃 total is the configured dictionary-memory budget. If both conditions hold, 𝐷 ∗ is published as the active dictionary. Otherwise, AgentZip retains the current active dictionary. AgentZip always uses the most recently published dictionary as the active dictionary for subsequent compression, allowing it to capture byte patterns that better reflect the cohort’s evolving runtime state. When a new dictionary becomes active, however, the previous dictionary cannot be removed immediately because pages compressed earlier may still depend on it for reconstruction. AgentZip therefore assigns each published dictionary a unique dict_id, and every dictionary-compressed page records the dict_id of the dictionary used during encoding. During restoration, AgentZip uses this identifier to retrieve the correct immutable dictionary. Each dictionary also maintains a reference count and is reclaimed only after no compressed page refers to it. Page Compression. When AgentZip processes an eligible 4 KiB private page 𝑃, it retrieves the active dictionary 𝐷 of the cohort. AgentZip initializes a Zstd encoder with 𝐷 and encodes the page as Zstd𝐷 (𝑃).
AgentZip (user space) Compression pool pool entry (key = VPN) payload
codec
metadata
Reconstruct 4 KiB page retrieve entry, decode payload install at same VA (UFFDIO_COPY)
Figure 3. AgentZip’s compression infrastructure. Compressed pages are stored in a user-space pool. Later accesses to compressed pages are intercepted by userfaultfd.
3.4
Lifecycle-Aware Compression Timing
AgentZip targets reducing the average memory footprint of sandboxes and therefore treats compression as a lifecycleaware service. The key idea is to separate tool-time discovery from llm-time compression. During tool execution, AgentZip runs a lightweight compressibility scout. The scout only observes and scores pages. It estimates potential compression savings and ranks high-value candidates. When the sandbox enters an idle period waiting for LLM thinking, AgentZip uses scout results to guide actual compression.
4
AgentZip Design
4.1
Compression Infrastructure
Compression Algorithm
As shown in Figure 3, AgentZip builds its compressed-memory infrastructure around a user-space compression pool and the Linux userfaultfd (UFFD) [15]. The compression pool stores compressed page contents, while UFFD allows AgentZip to detect and handle later accesses to these pages. UFFD can transfer page-fault handling from the kernel to AgentZip. When AgentZip compresses a sandbox page, it stores a compressed representation in the user-space compression pool. Each pool entry contains the compressed payload, the compression algorithm used for encoding, and the associated metadata required to reconstruct the original page. After the compressed representation is safely stored, AgentZip releases the page’s original 4 KiB physical frame. We refer to such a page as a reclaimed page. AgentZip registers the reclaimed page with UFFD. When the guest accesses it again, UFFD pauses the access and sends a page-fault event to AgentZip. AgentZip retrieves the compressed representation, reconstructs the original 4 KiB content, and installs it back at the same address using UFFDIO_COPY. 5
Page Reconstruction. For reconstructing a dictionarycompressed page, AgentZip reads the stored dict_id and retrieves the exact dictionary used during compression. Let 𝐵 denote the stored compressed payload and let 𝐷 id denote the dictionary identified by the stored dict_id. AgentZip reconstructs the page as Zstd𝐷−1id (𝐵).
Page Reconstruction. To reconstruct the page, AgentZip reads the encoded pairs in order. For each pair (𝑏𝑘 , ℓ𝑘 ), it writes byte value 𝑏𝑘 exactly ℓ𝑘 times. It then concatenates all reconstructed groups to obtain the original page: 𝑃b = 𝑏 1𝑏 1 · · · 𝑏 1 ∥ 𝑏 2𝑏 2 · · · 𝑏 2 ∥ · · · ∥ 𝑏𝑚𝑏𝑚 · · · 𝑏𝑚 | {z } | {z } | {z } ℓ1 bytes
4.2.2 Template-Delta Compression. Template-delta compression exploits the copy-on-write structure of agent sandboxes. Each sandbox is derived from an immutable template that remains available throughout the lifetime of its descendants. Because the template is never modified after sandbox creation, template pages at each virtual page index provides a stable reference for both compression and reconstruction. For a sandbox-private page at virtual page index 𝑖, let 𝑃𝑖 denote its current content and let 𝑇𝑖 denote the immutable template page at the same index. AgentZip stores the differences between 𝑃𝑖 and 𝑇𝑖 instead of storing the entire page. Page Compression. AgentZip divides each page into 𝑁 fixed-size blocks of 𝐵 bytes. We use 𝑃𝑖( 𝑗 ) and 𝑇𝑖( 𝑗 ) to denote the 𝑗-th blocks of the private page and template page, respectively. AgentZip constructs a change bitmap ( 1, 𝑃𝑖( 𝑗 ) ≠ 𝑇𝑖( 𝑗 ) , (𝑗) 𝑚𝑖 = 0, 𝑃𝑖( 𝑗 ) = 𝑇𝑖( 𝑗 ) .
ℓ2 bytes
ℓ𝑚 bytes
4.2.4 Codec Selection and Admission. For each candidate page, AgentZip evaluates all available compression codecs. It computes the complete storage cost of each representation, including both the compressed payload and its metadata. AgentZip then selects the codec that produces the smallest representation for final compression: 𝐶 ∗ (𝑃) = min {𝐶 dict (𝑃), 𝐶 TD (𝑃), 𝐶 RLE (𝑃)} , 4.3
Restore Prefetch Algorithm
Aggressive compression increases the likelihood that a reclaimed page will be accessed again, potentially triggering a page fault and increasing execution latency. To mitigate this cost, AgentZip learns page access patterns from previous restore events and proactively prefetches likely-needed compressed pages before they are accessed by the guest. 4.3.1 Prefetch Input Stream. AgentZip learns from demand page restores. A demand restore occurs when the guest accesses a page that is not in the physical memory. Let 𝑝𝑡 denote the page index restored by the 𝑡-th demand restore. The sequence 𝑝 1, 𝑝 2, . . . , 𝑝𝑡 forms the input training stream.
The encoded template delta is n o Δ𝑖 = 𝑀𝑖 , 𝑃𝑖( 𝑗 ) | 𝑚𝑖( 𝑗 ) = 1 , where 𝑀𝑖 is the change bitmap and 𝑚𝑖( 𝑗 ) = 1 indicates that the 𝑗-th block differs from the corresponding template block. Page Reconstruction. To reconstruct page 𝑃𝑖 , AgentZip first reads the immutable template page 𝑇𝑖 . It then uses the change bitmap 𝑀𝑖 to determine the source of each block. An unchanged block is copied directly from the template, whereas a changed block is read from the stored delta payload. The complete page is reconstructed as ( 𝑁 −1 𝑇 ( 𝑗 ) , 𝑚 ( 𝑗 ) = 0, 𝑖 𝑖 𝑃b𝑖 = ∥ (𝑗) (𝑗) = 1, 𝑗=0 Δ𝑖 , 𝑚𝑖
4.3.2 Prefetch Algorithms. AgentZip maintains three complementary prefetchers that capture different page restore patterns observed during sandbox execution. Stride prefetcher captures regular restore sequences. After restoring two consecutive pages 𝑝𝑡 −1 and 𝑝𝑡 , AgentZip computes their page-index difference 𝑠𝑡 = 𝑝𝑡 − 𝑝𝑡 −1 . If the same stride is repeatedly observed, AgentZip predicts 𝑝𝑡 + 𝑠𝑡 as a likely next page. Temporal prefetchers captures page-to-page restore correlations. When demand restore 𝑝𝑡 follows 𝑝𝑡 −1 , AgentZip records the transition 𝑝𝑡 −1 → 𝑝𝑡 . For each source page, AgentZip maintains a set of successor pages together with their observation counts and recency. AgentZip maintains two temporal predictors that learn these transitions at different scopes: a local temporal predictor for each sandbox and a cohort temporal predictor shared by sibling sandboxes. Local temporal predictor. It records transitions observed within an individual sandbox. When page 𝑝𝑡 is restored, AgentZip looks up the successors previously observed after 𝑝𝑡 in the same sandbox. This prefetcher captures restore sequences that repeat within a trajectory and adapts to the sandbox’s own execution history. Cohort temporal predictor. It shares transition history across sandboxes with same cohort_id. Each demand transition observed in one sandbox updates a cohort-level successor
where Δ𝑖( 𝑗 ) denotes the changed block stored in the delta payload and ∥ denotes byte concatenation. 4.2.3 RLE Compression. It captures repeated-byte redundancy within a single page. It is particularly effective for pages containing long regions with the same byte value, such as zero-like pages. Page Compression. AgentZip scans a page 𝑃 from beginning to end and groups adjacent bytes with the same value. Suppose this process produces 𝑚 groups. For the 𝑘-th group, 𝑏𝑘 denotes the repeated byte value, and ℓ𝑘 denotes the number of times that value appears consecutively. AgentZip stores each group using the pair (𝑏𝑘 , ℓ𝑘 ): RLE(𝑃) = (𝑏 1, ℓ1 ), (𝑏 2, ℓ2 ), . . . , (𝑏𝑚 , ℓ𝑚 ) . 6
Agent phase
>_
Tool execution
LLM inference (idle wait)
Scout
scan & score
idle
scout pushes
worker pops top-ranked
idle
compress & reclaim
Candidate queue
Worker
>_
the scout in descending order of estimated memory saving. For each candidate, AgentZip applies the most space-efficient codec, stores the compressed page in the compression pool, and then reclaims the page’s resident physical frame. Cooperative stop. When a new tool call arrives, AgentZip sends a cancellation request to the compression worker. Upon receiving the request, the worker stops launching new compression operations. Any candidate that has not yet modified the page mapping is abandoned, and any temporary compressed representation is released. An ongoing pagemapping update, however, cannot be safely interrupted. If cancellation arrives while AgentZip is reclaiming a page, the worker completes that single-page update before stopping. AgentZip serializes page-mapping updates so that guest execution never overlaps with an incomplete reclamation.
Tool execution
scan & score
idle
Cooperative stop: no new jobs start; only the in-flight page reclaim completes, so the next tool call is delayed by at most one page.
Figure 4. AgentZip lifecycle-aware scheduler. A lightweight scout identifies compression candidates during tool execution, while expensive compression during LLM waiting. set. This prefetcher is useful when sibling sandboxes execute related tool sequences, because a restore pattern can be learned in one sandbox before it is encountered in another. Tool-call hotset prefetcher. Sandboxes within the same cohort often access similar pages at nearly tool-call positions in their agent trajectories. AgentZip maintains a tool-callspecific restore history indexed by (cohort_id, tool_ordinal). For cohort 𝑐 and tool-call position 𝑎, it records the number of restores of each page 𝑝: 𝐻𝑐,𝑎 (𝑝) = #{restores of 𝑝 at (𝑐, 𝑎)}. Before another sandbox begins its 𝑎-th tool call, AgentZip prefetches top-𝐾 pages according to their restore frequency.
4.5
E2B provides a widely adopted sandbox interface for AIagent workloads [5, 19], exposing persistent Linux environments in which agents can execute commands, manipulate files, and preserve workspace state across tool calls. AgentZip provides an E2B-compatible frontend so that existing E2B-based agents can use AgentZip without modifying their prompts, tools, or orchestration logic. The E2B interface includes a control-plane API for sandbox lifecycle management and a per-sandbox envd API for command execution. AgentZip supports the subset required by our workloads through a host-side compatibility gateway. Existing E2B clients redirect their API endpoints to this gateway while continuing to use the original E2B SDK. Control-plane compatibility. The gateway translates Sandbox.create requests into AgentZip sandbox creation. The E2B templateID identifies the immutable template used to instantiate the persistent copy-on-write sandbox, while request metadata provides the request_id. AgentZip derives the corresponding cohort_id from the template and request identifiers for cohort dictionary compression and cohort-level prefetching. The gateway maintains a mapping between each E2B sandboxID and its AgentZip sandbox for subsequent lifecycle operations. AgentZip further namespaces sandbox, dictionary, and predictor state by tenant to prevent sharing across mutually untrusted users. Command compatibility. The gateway terminates E2B’s envd command interface and translates each commands.run request into an AgentZip guest-execution request. Command arguments, working directory, environment variables, user, and timeout are forwarded to the corresponding persistent sandbox, while the resulting standard output, error, and exit status are translated back into the format expected by E2B SDK. This translation preserves E2B programming interface while reusing AgentZip’s native sandbox execution path.
4.3.3 Prefetch Request Generation. AgentZip generates a prefetch request only when the page is marked as compressed. A valid candidate is inserted into a bounded asynchronous prefetch queue. For each queue entry, AgentZip retrieves the corresponding compressed metadata, and decodes the page. After reconstructing it, AgentZip uses UFFD to copy the page back into its physical memory and changes its state to resident-private. 4.4
E2B API Compatibility
Lifecycle-Aware Compression Scheduler
Agent workloads alternate between two distinct phases: tool execution, during which the sandbox actively consumes CPU, and LLM inference, during which the sandbox waits for the next model response. As shown in Figure 4, AgentZip exploits this lifecycle by performing only lightweight pagecandidate discovery during tool execution and deferring expensive page compression to subsequent LLM inference. Tool-time discovery. While a tool is running, AgentZip uses a lightweight scout to asynchronously evaluate the compression benefits of resident-private pages. For each page, the scout estimates how many bytes could be saved by compression. Pages with high estimated savings are placed in a candidate queue and ranked by their expected benefit. LLM-time compression. After a tool call completes, AgentZip performs compression while the sandbox waits for the next LLM response. It processes the pages identified by 7
5
Experimental Methodology
5.1
Experimental Setup
where 𝐵 private (𝑡) denotes the physical memory occupied by sandbox-private pages, and 𝐵 pool (𝑡) denotes the physical memory occupied by the user-space compression pool, including compressed page contents and associated metadata. We record 𝑀 (𝑡) once per second throughout each workavg load. For every workload 𝑤, we derive 𝑀𝑤 : the time-averaged sandbox-owned memory. The memory saving of AgentZip relative to its paired no-compression execution is
We implement AgentZip on top of Zeroboot [28], a KVMbased sandbox runtime that creates sandboxes from Firecracker memory snapshots using CoW cloning. We conduct experiments on a server equipped with Intel Xeon Platinum 8480C processors, running Linux 5.15.0. All sandboxes belonging to the same workload use the same snapshot as their template and initially share its memory through copy-onwrite mappings. Pages modified during execution become sandbox-owned private pages.
𝑥 𝑆𝑤 =1−
5.5 5.2
Agent Workloads
Latency Measurement
𝐿𝑤 =
6
Evaluation
6.1
Overall Results
𝑇AgentZip,𝑤 , 𝑇NoComp,𝑤
Figure 5 shows that AgentZip substantially reduces the sandbox memory footprint in both LLM training and inference workloads. On Rollout, AgentZip reduces average sandboxowned memory by 88.55%, compared with 48.66% for zswap and 51.24% for KSM+zswap. On GAF, AgentZip achieves a 64.29% reduction, whereas zswap and KSM+zswap reduce memory by only 4.86% and 21.25%, respectively. Figure 6 reports the corresponding end-to-end latency. On Rollout, AgentZip runs at 1.403× the no compression (NoComp) wall time, lower than both zswap at 1.436× and KSM+zswap at 1.517×. On GAF, AgentZip runs at 1.468× the NoComp wall time, compared with 1.118× for zswap and 1.159× for KSM+zswap. On Rollout, AgentZip therefore achieves both the largest memory saving and the lowest slowdown among the evaluated compression schemes, demonstrating the best overall memory-latency trade-off. Although AgentZip incurs moderately higher latency on GAF, it delivers substantially greater memory savings. Zswap: reactive compression timing. The primary limitation of zswap lies in its reactive trigger: it compresses pages only under memory pressure. This late trigger is poorly matched to short-lived agent sandboxes, where compressible pages may remain resident for most or all of a request and continue to contribute to the average memory footprint. AgentZip instead proactively identifies compressible pages during tool execution and reclaims them during LLM waiting intervals, decoupling compression from memory pressure. KSM+zswap: sandbox-oblivious redundancy detection. Most exact sharing among sibling sandboxes is already captured by template-backed copy-on-write mappings at sandbox creation. Once a write creates a private page, KSM can merge it only if its entire content is byte-identical to
Trace Replay
We evaluate AgentZip by replaying traces collected from representative agent workloads. Each trace records the sequence of tool actions together with the LLM inference latency preceding each tool call. To ensure fair comparison, each trace is generated once and replayed identically across all evaluated configurations. Before issuing a tool action, the replay waits for the recorded think_time_ms_before to reproduce the original LLM inference interval. During this period, the sandbox is marked as LLM-idle, allowing AgentZip to perform background compression. 5.4
, 𝑥 𝑀NoComp,𝑤
For each configuration, wall time is measured from the start of concurrent trajectory replay until the last sandbox completes. For workload 𝑤, we define AgentZip slowdown as
We construct the workloads from ten Python repositories in R2E-Gym [6]: aiohttp, coverage.py, DataLad, NumPy, Orange3, pandas, Pillow, Pyramid, Scrapy, and Tornado. To evaluate AgentZip under both LLM training and LLM inference settings, we use R2E-Gym to construct two representative sandbox workload patterns: parallel rollout for training and generate-and-filter (GAF) for inference. Parallel rollout. We emulate this scenario by generating 16 independent trajectories for each R2E task using DeepSeek-V4 [25]. All trajectories start from the same issue prompt and repository state. We use different LLM temperatures to obtain diverse tool-use behaviors. The 16 trajectory sandboxes execute concurrently and share a cohort identifier. Generate-and-filter. We emulate this scenario by generating four candidate trajectories for each selected R2E task. All candidates receive the same issue prompt, but use different role prompts (e.g., minimal patch, failure reproduction, test-guided repair, and root-cause diagnosis), and decoding temperatures. These settings encourage the candidates to follow different execution paths. The four trajectories are replayed concurrently in separate persistent sandboxes and share one cohort identifier. 5.3
𝑥 𝑀AgentZip,𝑤
Memory Measurement
Our primary memory metric is sandbox-owned physical memory. At time 𝑡, we define it as 𝑀 (𝑡) = 𝐵 private (𝑡) + 𝐵 pool (𝑡), 8
KSM + zswap
s y d o 3 w id tp py Py da ap nad ht La ge llo ram e. cr um ran r Pi an y aio rag Data o S N p T P O ve co
ea
s y d o 3 w id tp py Py da ap nad ht La ge llo ram e. cr um ran r Pi an y aio rag Data o S N p T P O ve co
n
M eo
G
64.29
(b) GAF
4.86 21.25
(a) Rollout
100 80 60 40 20 0 −10
AgentZip
48.66 51.24 88.55
Average memory saving (%)
zswap (Zstd)
n
ea
M eo
G
zswap (Zstd)
KSM + zswap
(a) Rollout
7× 5×
AgentZip
(b) GAF
3× 2× 1.5× 1× s y d o 3 w id tp py Py da ap nad ht La ge llo ram e. cr um ran r Pi an y aio rag Data o S N p T P O ve co
1.118× 1.159× 1.468×
1.436× 1.517× 1.403×
Wall slowdown (log scale)
Figure 5. Average sandbox-owned memory saving relative to the paired no-compression baseline across Rollout and GAF.
s y d o 3 w id tp py Py da ap nad ht La ge llo ram e. cr um ran r Pi an y aio rag Data o S N p T P O ve co
n ea
M eo
G
ea
n
M eo
G
Figure 6. End-to-end wall-time slowdown relative to the paired no-compression baseline across Rollout and GAF. Average saving
Memory saving (%)
100 81.9%
80
88.6% 88.6%
Wall slowdown
(b) GAF
4
4
75.1%
3
64.3% 3 55.2%
60 41.9%
40 24.7%
2
2
20 0
their corresponding immutable template pages. Cohort dictionary compression reduces average memory by 88.63% on Rollout and 75.14% on GAF, which confirms that substantial byte-level redundancy persists across sibling sandboxes even as their execution states diverge. The key insight is that combining complementary compression methods can substantially reduce compression cost while preserving most of the achievable memory saving. AgentZip uses lightweight RLE and template-delta compression whenever possible, while reserving cohort dictionary compression for pages that require cross-sandbox context. On Rollout, this reduces the number of dictionary-encoded pages by about 60%, while achieving nearly the same memory saving as dictionary-only compression (88.55% versus 88.63%) and reducing wall-time slowdown from 2.703× to 1.403×. This demonstrates that the codec portfolio preserves broad compression coverage while substantially reducing the cost of dictionary-based compression.
Wall slowdown
(a) Rollout
1
1
RLE Tmpl. Dict. AgentZip Delta
RLE Tmpl. Dict. AgentZip Delta
Figure 7. Effectiveness of AgentZip’s codec portfolio. another page. Even small differences prevent sharing despite substantial template-relative or cross-sandbox similarity. AgentZip targets this residual redundancy with templatedelta compression for pages that remain close to their template versions and cohort dictionary compression for shared byte patterns across sibling sandboxes. 6.2
6.3
Lifecycle-Aware Compression Timing
Figure 8 compares AgentZip with reactive compression and conventional proactive compression strategies discussed in Section 2.1. On Rollout, reactive strategy achieves essentially no average memory saving (−0.56%) at 1.027× wall time, while the proactive strategy reduces average memory by 84.04% at 1.538× wall time. AgentZip achieves the highest saving of 88.55% while reducing wall time to 1.403×. On GAF, the reactive strategy reduces average memory by only 11.73%. The generic strategy achieves 52.78% memory saving at 1.882× wall time, whereas AgentZip increases memory saving to 64.29% while reducing wall time to 1.468×.
Effectiveness of the Codec Portfolio
Figure 7 compares the memory savings achieved by each compression algorithm in isolation. RLE reduces average sandbox-owned memory by 24.74% on Rollout and 41.93% on GAF, indicating that repeated-byte and zero-like pages provide a meaningful but limited compression opportunity. Template-delta compression achieves substantially higher savings of 81.95% on Rollout and 55.24% on GAF, showing that many private copy-on-write pages remain similar to 9
Memory saving (%)
(b) GAF
AgentZip Proactive
80
Offline predictor potential Counterfactual rate (%)
(a) Rollout
100
AgentZip
60
Proactive
40 20
Reactive
Reactive
0 1.0
1.2
1.4
Wall slowdown
1.6
1.0
1.5
Wall slowdown
100 80 60 40 20 0
2.0
Rollout coverage Rollout precision GAF coverage GAF precision
Stride
+Local
+Cohort
Figure 10. Counterfactual coverage and precision.
Figure 8. Memory–latency trade-off of compression timing under the same compression algorithm portfolio. (b) Wall slowdown
Rollout GAF
0.6
0.4
0.2
0.0
ne
No
ide
Str
+L
oc
al hort tset o o +H +C
higher value indicates that more compressed pages are later brought back onto the guest’s critical path. Figure 9 reports the ablation study results of restore prefetch. Without prefetching, AgentZip achieves 94.22% average memory saving on Rollout and 75.96% on GAF, but restore amplification reaches 0.419 and 0.600, resulting in wall-time slowdowns of 3.052× and 2.755×, respectively. On Rollout, adding stride, local temporal, cohort temporal, and toolhotset prefetcher progressively reduces restore amplification from 0.419 to 0.349, 0.219, 0.170, and 0.147. The corresponding wall-time slowdown decreases from 3.052× to 2.645×, 1.784×, 1.602×, and finally 1.403×. On GAF, stride and local temporal prefetcher reduce restore amplification from 0.600 to 0.302 and 0.264, while reducing wall-time slowdown from 2.755× to 1.776× and 1.424×. Cohort temporal prefetcher further reduces restore amplification to 0.254, and the complete AgentZip prefetcher reaches 0.257 at 1.468× wall time. Figure 10 further evaluates the prediction opportunity using demand restore traces. On Rollout, stride prefetcher covers 14.72% of future demand restores with 58.49% precision. Adding local temporal prefetcher increases coverage to 70.16% with 78.05% precision, while cohort temporal prefetcher further increases coverage to 96.27% with 82.56% precision. On GAF, coverage increases from 37.94% with stride prefetcher to 82.39% with local temporal prefetcher and 89.06% with cohort temporal prefetcher, with the complete temporal predictor achieving 74.70% precision. These results demonstrate the key role of AgentZip’s restore prefetching. Aggressive compression exposes more memory-saving opportunities by compressing warm pages that conventional policies would normally retain. However, these pages are likely to be accessed again, triggering blocking UFFD restores that stall guest execution. By predicting which compressed warm pages will be needed again and restoring them before demand, AgentZip can compress warm pages aggressively without treating their likely reuse as a reason to leave them uncompressed. AgentZip makes these predictions using complementary prefetchers that exploit different access patterns in agent workloads.
3
Wall slowdown
Restore amplification
(a) Restore amplification
2
1
0
ne
No
ide
Str
rt al et oc oho ots +H +C
+L
Figure 9. Cumulative prefetch ablation. (a) Demand restores amplification normalized by the number of reclaimed pages. (b) End-to-end slowdown. These results demonstrate the benefit of aligning compression with the agent lifecycle. The reactive strategy compression waits for memory pressure and therefore misses most opportunities to reduce the time-averaged footprint of short-lived sandboxes. The conventional proactive strategy exposes more compression opportunities, but performs expensive scanning, encoding, and page reclamation without distinguishing foreground tool execution from LLM waiting periods. AgentZip instead performs lightweight discovery during tool execution and moves expensive compression and mapping updates into LLM waiting windows. As a result, AgentZip achieves a better memory–latency operating point than proactive strategy on both workloads. 6.4
Effectiveness of Restore Prefetching
We first quantify the performance cost of restoring compressed pages using restore amplification, defined as 𝑁 demand restores , 𝑁 reclaimed pages This metric captures how frequently reclaimed pages are subsequently accessed through blocking demand restores: a 𝐴restore =
10
25
75
100
(c) Cohort size
100 50
50
Progress (%)
1
2
Sandboxes
(b) Same-VA
100
80
50 100
4
50
100
25
50
75
Progress (%)
100
(d) Dictionary size
Dictionary (KiB)
Figure 11. Similarity and dictionary sensitivity study. 6.5
80 60 40 20 0
4 8 16 32 64 128
(a) Pool composition Latency (ms, log)
(a) Template delta
100
GAF Pool bytes (%)
Saving (%) Page fraction (%)
Rollout
(b) Restore latency 10 10 10 10
Rollout
GAF
RLE Template Dict. payload
Metadata Dictionaries
Decode Prefetch Demand
2
1
0
−1
p50
p95
p99
Figure 12. AgentZip compression and restore overheads. (a) Breakdown of compression-pool memory usage. (b) Latency of codec decoding, asynchronous prefetch restoration, and blocking demand restoration.
Similarity and Dictionary Sensitivity
AgentZip’s compression design is motivated by two sources of memory similarity: template-relative similarity and crosssandbox similarity. This experiment answers two questions: whether these similarities remain present as agent executions progress, and how the cohort size and dictionary size affect AgentZip’s ability to convert them into memory savings. Figures 11(a) and (b) validate template-relative and crosssandbox similarity, respectively, while Figure 11(c) and (d) evaluate the configuration of the cohort dictionary used to exploit cross-sandbox redundancy Figures 11(a) and (b) show that substantial redundancy persists throughout agent execution. On Rollout, 96.26% of pages contain the same content as the sibling sandboxes at the corresponding virtual address at 25% of execution, and this fraction remains 75.87% at completion. This shows that sibling trajectories retain substantial memory similarity even after their executions diverge. GAF shows lower crosssandbox agreement, with about 48–51% of pages matching the majority content at the corresponding virtual address, reflecting the greater diversity of independently generated candidates. Nevertheless, template-relative similarity remains high in both workloads: the fraction of pages profitably compressible with template delta ranges from 84.64% to 96.25% on Rollout and increases from 82.10% to 90.34% on GAF. These results validate AgentZip’s use of complementary compression mechanisms: cohort dictionaries exploit redundancy shared across sibling sandboxes, while template delta continues to capture private pages even when their exact contents have diverged. Figures 11(c) and (d) show that cross-sandbox dictionary compression benefits from choosing both cohort size and dictionary capacity carefully. On Rollout, dictionary-only memory saving increases from 77.83% with one sandbox to 91.08% with two and 93.55% with four, indicating that additional sibling sandboxes provide useful shared patterns. GAF shows a different trend: saving increases only slightly from 85.81% with one candidate to 86.26% with two, but drops to 71.39% with four, suggesting that more diverse candidates
introduce patterns that are less useful for the pages being compressed. Dictionary capacity shows a similar trade-off. Rollout achieves its highest saving of 94.83% with a 16-KiB dictionary, while GAF peaks at 66.31% with 8 KiB; increasing the dictionary to 128 KiB reduces saving to 80.38% and 44.46%, respectively. Thus, adding more sandboxes or allocating more dictionary space does not necessarily improve compression. AgentZip addresses this trade-off by validating candidate dictionaries on held-out samples and accounting for dictionary storage before publication, rather than simply using the largest available cohort or dictionary. 6.6
Memory Overheads
Figure 12(a) reports the memory overhead of AgentZip’s compression pool. On Rollout, template-delta and dictionary payloads account for 40.56% and 55.14% of pool bytes, while blob metadata and immutable dictionaries account for only 3.09% and 1.22%, respectively. On GAF, dictionary and template-delta payloads account for 80.45% and 13.88%, while metadata and immutable dictionaries account for 4.09% and 1.55%. Overall, auxiliary metadata and dictionary storage constitute only 4.31% of the pool on Rollout and 5.64% on GAF. The complete compression pool, including all payload and metadata overheads, further accounts for 28.9% and 6.1% of profiled sandbox-owned memory on Rollout and GAF. Figure 12(b) reports the restore-path latency for compressed pages. Codec decoding takes 0.08 ms, 1.28 ms, and 9.21 ms at p50, p95, and p99, respectively, while asynchronous prefetch restoration takes 0.16 ms, 1.50 ms, and 8.09 ms. In contrast, demand restoration takes 3.47 ms at p50, 110.52 ms at p95, and 223.27 ms at p99. These results show that AgentZip introduces little auxiliary memory overhead: more than 94% of the compression pool stores useful compressed page contents rather than metadata or dictionaries. More importantly, codec reconstruction itself is inexpensive compared with a blocking 11
demand restore, whose tail latency is over an order of magnitude larger. This distinction validates AgentZip’s design choice to focus on restore prefetching rather than only optimizing compression and decompression latency: moving restoration off the demand-fault critical path provides substantially greater performance benefit while preserving the large memory savings enabled by aggressive compression.
7
[12] Mengming Li, Qijun Zhang, Yichuan Gao, Wenji Fang, Yao Lu, Yongqing Ren, and Zhiyao Xie. 2025. Profile-Guided Temporal Prefetching. In ISCA. [13] Mengming Li, Qijun Zhang, Yongqing Ren, and Zhiyao Xie. 2025. Integrating Prefetcher Selection with Dynamic Request Allocation Improves Prefetching Efficiency. In HPCA. [14] Linux Kernel Documentation. [n. d.]. Kernel Samepage Merging. Retrieved September 1, 2026 from https://docs.kernel.org/admin-guide/ mm/ksm.html [15] Linux Kernel Documentation. [n. d.]. Userfaultfd. https://docs.kernel. org/admin-guide/mm/userfaultfd.html. Accessed: 2026-08-10. [16] Linux Kernel Documentation. [n. d.]. zram: Compressed RAM-based Block Devices. https://docs.kernel.org/admin-guide/blockdev/zram. html. Accessed: 2026-08-25. [17] Sparsh Mittal. 2016. A survey of recent prefetching techniques for processor caches. CSUR (2016), 1–35. [18] Kangqi Ni, Wenyue Hua, Xiaoxiang Shi, Jiang Guo, Shiyu Chang, and Tianlong Chen. 2026. Chimera: Latency- and PerformanceAware Multi-agent Serving for Heterogeneous LLMs. arXiv preprint arXiv:2603.22206 (2026). [19] OpenAI. 2026. Sandbox Clients in the OpenAI Agents SDK. https: //openai.github.io/openai-agents-python/sandbox/clients/. [20] Gagandeep Panwar, Muhammad Laghari, David Bears, Yuqing Liu, Chandler Jearls, Esha Choukse, Kirk W. Cameron, Ali R. Butt, and Xun Jian. 2022. Translation-Optimized Memory Compression for Capacity. In MICRO. 992–1011. [21] Guangming Sheng, Chi Zhang, Zilingfeng Ye, Xibin Wu, Wang Zhang, Ru Zhang, Yanghua Peng, Haibin Lin, and Chuan Wu. 2025. HybridFlow: A Flexible and Efficient RLHF Framework. In EuroSys. [22] Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. 2025. Openhands: An open platform for ai software developers as generalist agents. In ICLR, Vol. 2025. 65882–65919. [23] Johannes Weiner, Niket Agarwal, Dan Schatzberg, Leon Yang, Hao Wang, Blaise Sanouillet, Bikash Sharma, Tejun Heo, Mayank Jain, Chunqiang Tang, et al. 2022. TMO: Transparent memory offloading in datacenters. In ASPLOS. 609–621. [24] Hao Wu, Krishnendra Nathella, Matthew Pabst, Dam Sunwoo, Akanksha Jain, and Calvin Lin. 2021. Practical temporal prefetching with compressed on-chip metadata. IEEE Trans. Comput. (2021), 2858–2871. [25] Anyi Xu, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, Chenchen Ling, et al. 2026. Deepseek-v4: Towards highly efficient million-token context intelligence. arXiv preprint arXiv:2606.19348 (2026). [26] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agentcomputer interfaces enable automated software engineering. NIPS (2024), 50528–50652. [27] Ethan G. Young, Pengfei Zhu, Tyler Caraza-Harter, Andrea C. ArpaciDusseau, and Remzi H. Arpaci-Dusseau. 2019. The True Cost of Containing: A gVisor Case Study. In HotCloud. [28] Zeroboot. 2026. Zeroboot: Sub-millisecond VM Sandboxes for AI Agents via Copy-on-Write Forking. https://github.com/zerobootdev/ zeroboot. Accessed: 2026-08-25. [29] Hao Zhang, Mingjie Liu, Shaokun Zhang, Songyang Han, Jian Hu, Zhenghui Jin, Yuchi Zhang, Shizhe Diao, Ximing Lu, Binfeng Xu, Zhiding Yu, Jan Kautz, and Yi Dong. 2026. ProRL Agent: Rollout-asa-Service for RL Training of Multi-Turn LLM Agents. arXiv preprint arXiv:2603.18815 (2026).
Conclusion
High-fanout agent workloads make sandbox memory a firstorder scaling bottleneck, but also expose redundancy and execution structure that conventional memory-management mechanisms fail to exploit. AgentZip exploits these properties by compressing redundancy across sibling sandboxes and against their shared template, aligning expensive compression with LLM waiting periods, and predicting future restores so that warm pages can be compressed aggressively without relying on conservative page selection. Together, these techniques show that agent sandboxes should not be treated as independent general-purpose workloads: their shared origins, correlated executions, and repeated idle intervals provide system-level opportunities to substantially increase deployment density while controlling the performance cost of aggressive memory compression.
References [1] 2020. zswap – The Linux Kernel Documentation. https://www.kernel. org/doc/html/v5.8/vm/zswap.html. [2] Alexandru Agache, Marc Brooker, Alexandra Iordache, Anthony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa. 2020. Firecracker: Lightweight Virtualization for Serverless Applications. In NSDI. [3] Sam Ainsworth and Lev Mukhanov. 2024. Triangel: A HighPerformance, Accurate, Timely On-Chip Temporal Prefetcher. In ISCA. [4] Jonathan Corbet. 2013. The zswap compressed swap cache. https: //lwn.net/Articles/537422/. [5] E2B. 2026. E2B: Secure Sandboxes for AI Agents. https://e2b.dev/. [6] Naman Jain, Jaskirat Singh, Manish Shetty, Liang Zheng, Koushik Sen, and Ion Stoica. 2025. R2e-gym: Procedural environments and hybrid verifiers for scaling open-weights swe agents. arXiv preprint arXiv:2504.07164 (2025). [7] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. Swe-bench: Can language models resolve real-world github issues?. In ICLR. 54107–54157. [8] Sunil Kim and Alexander V Veidenbaum. 1997. Stride-directed prefetching for secondary caches. In ICPP. 314–321. [9] Sandeep Kumar, Aravinda Prasad, and Sreenivas Subramoney. 2026. TierScape: Harnessing Multiple Compressed Tiers to Tame Server Memory TCO. In EuroSys. 247–262. [10] Andres Lagar-Cavilla, Junwhan Ahn, Suleiman Souhlal, Neha Agarwal, Radoslaw Burny, Shakeel Butt, Jichuan Chang, Ashwin Chaugule, Nan Deng, Junaid Shahid, et al. 2019. Software-defined far memory in warehouse-scale computers. In ASPLOS. 317–330. [11] H. Andrés Lagar-Cavilla, Junwhan Ahn, Suleiman Souhlal, Neha Agarwal, Radoslaw Burny, Shakeel Butt, Jichuan Chang, Ashwin Chaugule, Nan Deng, Junaid Shahid, Greg Thelen, Kamil Adam Yurtsever, Yu Zhao, and Parthasarathy Ranganathan. 2019. Software-Defined Far Memory in Warehouse-Scale Computers. In ASPLOS. 317–330. 12