Memory Compression for High-Fanout Agent Sandboxes

1 Introduction

• High-fanout workloads make memory the resource that usually runs out first, while sibling sandboxes share template pages and develop similar runtime states.Measurements found 76–96% of pages exhibited template-relative or cross-sandbox redundancy.Source: §1 · pp. 1–2
• Conventional compression misses approximate similarity across private pages, conservatively excludes many warm pages, and may compress too late or during foreground execution.The introduction frames these mismatches as decisions about how, what, and when to compress.Source: §1 · p. 2
• AgentZip combines template-relative deltas, shared dictionaries across sibling sandboxes, and lightweight intra-page compression, choosing the most space-efficient representation per page.These representations capture redundancy beyond exact page equality.Source: §1 · p. 2
• AgentZip compresses any page with a profitable representation and prefetches predicted restores, while moving expensive compression into LLM waiting periods.Lightweight candidate discovery runs during tool execution; expensive compression is deferred to LLM waits.Source: §1 · p. 2
• AgentZip reduces sandbox-owned memory by up to 8.7×, four times more than Linux, while reducing aggressive-compression slowdown from 3.1× to 1.40×.The slowdown reduction retains nearly all of the memory-saving benefit.Source: §1 · pp. 2–3

2.1 Memory Compression

• Memory compression reclaims physical frames by storing smaller compressed representations, but a later access requires retrieval and decompression before execution continues.Its effectiveness depends jointly on redundancy model, scope, and timing.Source: §2.1 · p. 3

2.2 Compression Redundancy Model

• KSM deduplicates identical pages and zswap compresses pages independently, but neither captures approximate similarity between private pages and templates or sibling sandboxes.Much exact sharing is already handled by copy-on-write at sandbox creation.Source: §2.2 · p. 3

2.3 Compression Scope

• Cold-page selection limits savings because warm pages may be compressible, while expanding compression to warm pages increases restore overhead.A prior study reported savings rising from 11% to 32% and slowdown from 9.5% to 20% when extending compression to cold-plus-warm pages.Source: §2.3 · p. 3

2.4 Compression Timing

• Reactive compression can start too late to reduce average footprint, while generic proactive compression may interfere with foreground tool execution.Agent sandboxes therefore need proactive timing coordinated with execution phases.Source: §2.4 · p. 3

3 Overview

• AgentZip’s workflow combines a sandbox-aware compression portfolio, a scheduler for compression timing, and asynchronous prefetching of predicted page restores.Likely-needed pages are restored before they trigger demand faults.Source: §3 · pp. 3–4, Figure 2 · p. 4

3.1 Sandbox Model

• Sandboxes fork or clone from an immutable template, initially sharing pages until writes create private copies through copy-on-write.The template contains base operating-system state, libraries, package environments, and dependencies.Source: §3.1 · p. 4

3.2 Sandbox-Aware Compression Algorithm

• AgentZip uses cohort dictionaries for cross-sandbox similarity, template-page deltas for template similarity, and local codecs for within-page patterns.It targets private pages that remain close to their corresponding template pages as well as common byte patterns across related sandboxes.Source: §3.2 · p. 4

3.3 Restore Prefetch Instead of Page Selection

• AgentZip replaces hotness-based compression selection with profitable-page compression and restore-time prediction, using complementary predictors for restore patterns.The predictors capture sequential strides, page-to-page temporal correlations, and pages frequently restored at tool-execution beginnings.Source: §3.3 · p. 4

3.4 Lifecycle-Aware Compression Timing

• A lightweight scout scores candidate pages during tool execution, then AgentZip performs actual compression while the sandbox waits for LLM output.This separates tool-time discovery from LLM-time compression.Source: §3.4 · p. 5

4.1 Compression Infrastructure

• AgentZip stores compressed page contents and metadata in a user-space pool, releases the original 4 KiB frame, and restores the page at the same address on access.UFFD detects accesses to reclaimed pages and sends page-fault events to AgentZip for reconstruction.Source: §4.1 · p. 5

4.2 Compression Algorithm

• Template deltas, cohort dictionaries, and RLE target complementary redundancy in sandbox pages.Template-delta compression stores differences from the immutable page at the same index; cohort dictionaries capture common byte patterns across sibling sandboxes, while RLE captures repeated bytes within a page.Source: §4.2.1 · p. 5, §4.2.2 · p. 6, §4.2.3 · p. 6
• For each candidate page, AgentZip selects the codec with the smallest representation cost, including payload and metadata, and publishes dictionaries only when validation savings and the global dictionary budget conditions are met.Previously published dictionaries remain available for pages that depend on them during reconstruction.Source: §4.2.1 · p. 5, §4.2.4 · p. 6

4.3 Restore Prefetch Algorithm

• AgentZip learns from demand restores and uses stride, temporal, and tool-call-position patterns to prefetch likely-needed compressed pages before guest access.Its temporal predictors capture local sandbox transitions and transitions shared across cohort siblings.Source: §4.3 · p. 6, §4.3.1 · p. 6, §4.3.2 · pp. 6–7

4.4 Lifecycle-Aware Compression Scheduler

• A lightweight scout finds candidates during tool execution, while AgentZip performs costly compression during LLM waits and cooperatively stops when a new tool call arrives.Page-mapping updates already in progress are completed before the worker stops.Source: §4.4 · p. 7, Figure 4 · p. 7

4.5 E2B API Compatibility

• An E2B-compatible gateway translates sandbox lifecycle and command requests into AgentZip operations while forwarding command settings and returning expected outputs and status.Sandbox, dictionary, and predictor state is namespaced by tenant.Source: §4.5 · p. 7

5.1 Experimental Setup

• AgentZip is implemented on Zeroboot with KVM-based sandboxes cloned from Firecracker snapshots and evaluated on Linux 5.15.0.Sandboxes share template memory through copy-on-write; modified pages become sandbox-owned private pages.Source: §5.1 · p. 8

5.2 Agent Workloads

• Workloads use ten Python repositories and model parallel-rollout training and generate-and-filter inference patterns.Rollout runs 16 concurrent trajectories; generate-and-filter replays four concurrent candidate trajectories with varied roles and temperatures.Source: §5.2 · p. 8

5.3 Trace Replay

• Collected traces record tool actions and preceding LLM latency, then replay identically across configurations with LLM-idle intervals available for background compression.Before each tool action, replay waits for its recorded think time.Source: §5.3 · p. 8

5.4 Memory Measurement

• Sandbox-owned physical memory is the primary memory metric, including private-page memory and the compression pool; memory is sampled once per second.The pool includes compressed page contents and associated metadata.Source: §5.4 · p. 8

5.5 Latency Measurement

• Wall time runs from concurrent replay start until the last sandbox finishes, and AgentZip slowdown is defined per workload.The latency measurement compares configurations over the full concurrent trajectory replay.Source: §5.5 · p. 8

6.1 Overall Results

• AgentZip cuts average sandbox-owned memory by 88.55% on Rollout and 64.29% on GAF; wall time is 1.403× and 1.468× the NoComp baseline, respectively.On Rollout, these savings exceed zswap’s 48.66% and KSM+zswap’s 51.24%; on GAF, those baselines save 4.86% and 21.25%.Source: §6.1 · p. 8, Figure 5 · p. 9, Figure 6 · p. 9

6.2 Effectiveness of the Codec Portfolio

• On Rollout, the codec portfolio retains 88.55% memory saving versus 88.63% for dictionary-only compression, while reducing slowdown from 2.703× to 1.403×.Template-delta saves 81.95% on Rollout and 55.24% on GAF; cohort dictionaries save 88.63% and 75.14%, respectively.Source: Figure 7 · p. 9, §6.2 · p. 9

6.3 Lifecycle-Aware Compression Timing

• Against generic proactive timing, AgentZip raises memory saving from 84.04% to 88.55% at 1.403× versus 1.538× wall time on Rollout, and from 52.78% to 64.29% at 1.468× versus 1.882× on GAF.AgentZip performs lightweight candidate discovery during tool execution and defers expensive compression to LLM inference waits.Source: §6.3 · pp. 9–10, Figure 8 · p. 10

6.4 Effectiveness of Restore Prefetching

• Without prefetching, slowdown reaches 3.052× on Rollout and 2.755× on GAF; complete prefetching reduces it to 1.403× and 1.468×, respectively.On Rollout, prefetch coverage rises to 96.27% with cohort temporal prefetching; predicting reuse lets AgentZip compress warm pages and restore them before demand.Source: Figure 9 · p. 10, §6.4 · p. 10, Figure 10 · p. 10

6.5 Similarity and Dictionary Sensitivity

• Dictionary-only savings rise from 77.83% with one sandbox to 93.55% with four on Rollout, but GAF peaks at 86.26% with two and drops to 71.39% with four.Capacity also matters: Rollout peaks at 94.83% with a 16-KiB dictionary, while GAF peaks at 66.31% with 8 KiB; at 128 KiB, savings are 80.38% and 44.46%. Template-delta-compressible pages range from 84.64% to 96.25% on Rollout and 82.10% to 90.34% on GAF.Source: Figure 11 · p. 11, §6.5 · p. 11

6.6 Memory Overheads

• Auxiliary metadata and dictionary storage use 4.31% of the compression pool on Rollout and 5.64% on GAF; blocking demand restoration takes 110.52 ms at p95 and 223.27 ms at p99.The complete pool accounts for 28.9% of profiled sandbox-owned memory on Rollout and 6.1% on GAF; codec reconstruction is inexpensive relative to blocking demand restores.Source: Figure 12 · p. 11, §6.6 · pp. 11–12

• AgentZip compresses redundancy across sibling sandboxes and against their shared template, while aligning expensive compression with LLM waiting periods.It also predicts future restores so warm pages can be compressed aggressively without conservative page selection.Source: §7 · p. 12
• High-fanout agent workloads expose shared origins, correlated executions, and repeated idle intervals that conventional memory-management mechanisms fail to exploit.Source: §7 · p. 12
• These techniques provide system-level opportunities to increase deployment density while controlling the performance cost of aggressive memory compression.Source: §7 · p. 12