Snapshot and Restore

Builds on Common Methodology

Times how long a provider takes to save a sandbox snapshot, create a new sandbox from it, and run the first Python, Node.js, and git command.

Agent harnesses and reinforcement learning loops use snapshots to save a configured sandbox once and boot clean copies from that state without repeating installation or repository setup.

The Snapshots tab measures two patterns built on that primitive:

• Snapshot and Restore times saving a snapshot of a configured sandbox, creating one new sandbox from that snapshot after the source sandbox is destroyed, and loading the Python, Node.js, and git runtimes inside it.
• Fork takes one snapshot and creates four sandboxes from it one after another to measure restore speed and whether later restores accelerate as the provider caches the snapshot.

View the Procedure View Snapshot and Restore Results Download Raw Data View the Parameters

Metrics

Snapshot and Restore is the sum of three timed stages: Snapshot (saving the configured source sandbox), Create from Snapshot (booting a new sandbox after the source sandbox is destroyed), and Load Runtimes (running the first chained python3, node, and git command inside the restored sandbox).

Timed Part	Starts	Ends
Snapshot	The snapshot request	The snapshot operation completes and returns
Create from Snapshot	The create-from-snapshot request	The call returns with the new sandbox
Load Runtimes	The command	Its result and sandbox clock readings return

Measurement

Each trial uses 2 sequential sandboxes created from BoxRouter's pinned standard image on providers that support the snapshots capability through BoxRouter.

1. Create source sandbox, run readiness check, and write a marker file. Each trial writes boxrouter-snapshot-marker/v1 to /workspace/snapshot/marker.
2. Snapshot Time Take a snapshot (Snapshot). Timed The harness times snapshots.create.
3. Destroy source sandbox and confirm deletion. The harness destroys the source sandbox untimed so the restore cannot depend on the live parent container.
4. Snapshot Time Restore a new sandbox from the snapshot (Create from Snapshot). Timed
5. Run the chained Python, Node.js, and git command (Load Runtimes). Timed
6. Verify the marker file, destroy the restored sandbox, and delete the snapshot.

The Load Runtimes step runs without a prior readiness check, importing standard-library modules in python3 (json, sqlite3, ssl, asyncio, urllib.request, email.parser, xml.etree.ElementTree) and node (crypto, zlib, http) and running git --version to fault in binary and library pages from the snapshot.

Scope Limits and Caveats

• Providers differ in whether snapshots capture filesystem state alone or both filesystem and memory.
• E2B snapshots capture the VM memory as well as the filesystem, while Modal, Vercel and Daytona capture the filesystem only; a snapshot that keeps memory takes longer to save and may start faster.
• Providers handle the source sandbox differently during snapshots.create (Vercel stops it, E2B pauses it briefly, Modal and Daytona keep it running), and the procedure destroys it before every restore.
• Modal's API has no lookup to confirm that a snapshot is gone after deletion, so the benchmark script sends the delete call and records the confirmation as not checkable.

Failures and Exclusions

Outcome classifications, top-up rounds, and outlier rules follow Common Methodology; the first failed step ends the trial without in-trial retries.

A trial succeeds only when Snapshot, Create from Snapshot, and Load Runtimes complete within timeout, the restored sandbox contains the expected /workspace/snapshot/marker content, and both sandboxes and the snapshot are confirmed deleted.

Step	Time Limit
Create source sandbox	5 min
Write marker	30 s
Snapshot	10 min
Destroy source	5 min
Create from Snapshot	5 min
Load Runtimes	100 s
Verify marker	30 s
Destroy restored sandbox	5 min

Statistics

Based On

Common Methodology

Per-unit percentiles, bootstrap confidence intervals, and tail rules follow Common Methodology.

A provider is ranked once it has at least 20 successful trials.

Sandbox and Trials

Image Digest

sha256

Image Version

0.3.11

Image Registry Page

View on the Registry

Pull the Image

docker pull ghcr.io/boxrouter/standard-image@sha256:89d4c97048dbdfb8b6d85ad91833962ff38d1c334a5f47e6de80a9762310191b Copy

Lifetime

15.0 min

Idle Connection Time

5.0 min

From Common Methodology

Idle Connection Exceptions

Provider	Rule	File Transfer Idle Time
Daytona	The SDK has no idle-timeout setting. Its command channel keeps its connection open, and its file-transfer channel reconnects after 5 s of idle time.	5.0 s

From Common Methodology

Network Path Attempts

10

From Common Methodology

Mode

Sequential

Sandboxes per Trial

2

Parallel Trials

10

Concurrent Sandboxes

1

Provider Requirements

Required

Snapshots

At a Glance

Metrics

• Snapshot Time
• Restore Time
• First Command Time

Quantity

Time

Unit

Milliseconds (ms)

Direction

Lower Is Better

Statistic

Median

Clock

Job-host clock

Machine Size

2 vCPU / 4 GiB

Trials

40

Variants

• Standard sandbox with marker file