Agent sandboxes / PaperPod alternative

A PaperPod.dev alternative for state beyond small agent-memory files

PaperPod bundles shell/code execution, background processes, preview URLs, browser rendering, model calls and a small persistent Agent Memory store. Session reuse and memory files serve different purposes. Compare those tools with the complete evolving Linux filesystem your returning agent needs.

Reviewed 2026-10-18 · Published by the Sandbox0 team

When PaperPod fits

PaperPod fits an agent that benefits from a single CLI/HTTP/WebSocket surface for one-shot execution, previews, headless browsing, and on-demand model calls. Its separate memory API can carry small task/context files through sandbox resets.

When to consider Sandbox0

Consider Sandbox0 when installed tools, configuration, dependencies and outputs should share one durable whole RootFS that expands online. Supply any required browser rendering, model integrations, interpreter convenience layer and application memory separately.

Capabilities

PaperPod and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimePaperPodNot established in this reviewSandbox0ttl and hard_ttl default to 0 (disabled). Configure idle pause and deletion policies for the same persistent sandbox identity; an idle running sandbox still accrues compute charges.Read documentation →
Persistent filesPaperPodAgent Memory stores up to 10 MB per user across sandbox resets; execution-session files are a separate scope.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSPaperPodSession reuse and the memory store do not establish retained complete writable RootFS coverage.View evidence ↗Sandbox0Persistence extends beyond /workspace to paths such as /usr/local, /etc, and /home. Runtime tmpfs and virtual filesystems are excluded.Read documentation →
Release compute, keep statePaperPodBackground processes and reconnection are documented, but a compute-release machine pause contract is not established.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process statePaperPodPersistent context files do not establish arbitrary RAM/process checkpoint restoration.View evidence ↗Sandbox0Experimental memory checkpoints can preserve compatible process state. Use memory: true on both pause and resume on a compatible deployment. A filesystem checkpoint alone does not preserve running processes.Read documentation →

Online RootFS growth

On growth-enabled images, Sandbox0 automatically expands the writable RootFS as free space runs low, within a configured sparse logical ceiling up to 64 TiB. Agent processes keep running. Growth is enabled in the qualified Cloud region; confirm activation for other regions. Existing images and snapshots retain their captured storage geometry. The ceiling is logical capacity, not preallocated host disk.

The reviewed docs establish a 10 MB persistent memory store and separate execution files, but not automatic online growth of an entire durable RootFS. Sandbox0 addresses accumulated system tools and data within the existing machine filesystem.

Files while compute is paused

Sandbox0's Files API reads persistent files without resuming compute. Filesystem-only pauses also permit edits; retained-memory pauses are read-only and reject mutations with 409. SSH, SFTP, file watching, and runtime-only mounts require running compute.

See paused file operations →

Session files and persistent Agent Memory are separate surfaces

The docs offer sessionId for reusing sandbox execution state, while the memory API explicitly survives sandbox resets and has a 10 MB per-user quota. Saving context there is useful, but it does not establish persistence of every installed package, system path or large output on the execution machine.

Background processes still need lifecycle validation

PaperPod supports starting, listing and stopping background processes and exposing their ports. Those APIs are relevant for agent servers and builds. The reviewed docs do not establish arbitrary process-memory checkpoint/restore, an indefinite active lifetime, or automatic whole-RootFS expansion; test the effective session/reset behavior before moving a returning agent.

The meter is per operation, not a universal allocated VM-hour

The public docs bill execution, background processes and browser operations by the second, with file/memory calls included. WebSocket billing is per operation rather than per connection. Model operations use neurons, a separate unit; the headline typical-session cost is an illustrative workload rather than an equal-resource machine quote.

Pricing

Compare billing models, then price your workload

CPU allocation, memory, billing minimums, disk, plan fees, and supported workload differ. These meters are not equal-performance machine quotes. Confirm region, resource units, and included allowances before estimating a total.

PaperPod

Pricing reviewed 2026-10-18

Execution / background processes
$0.0001 per metered second
Rate source ↗
Browser operations
$0.0001 per metered second
Rate source ↗
File I/O and Agent Memory
Included with no extra operation charge
Persistent Agent Memory quota is 10 MB per user.
Rate source ↗
Model operations
$0.02 per 1,000 neurons
A different product meter from sandbox compute.
Rate source ↗
Subscription / minimum
No subscription or minimum advertised
Rate source ↗

No CPU/RAM allocation is inferred from the flat operation price. Confirm concurrent operations, session lifetime and billing attribution for the actual workflow. Free signup credit is one-time; an example short coding session is not a production cost benchmark.

Check current PaperPod pricing ↗

Sandbox0

$0.015/GiB-hour compute (billed by the second at approximately $0.000004167/GiB-second), plus $0.02/GiB-month of retained incremental RootFS and memory checkpoint data. Shared base images and platform recovery retention are excluded; paused sandboxes accrue storage charges only.

Compute / GiB-hour
$0.015
Retained data / GiB-month
$0.02
Paused compute
$0.00

A 4 GiB agent, 100 running hours

$6.00 compute

4 GiB × 100 hours, billed by the second. Keeping 20 GiB of billable incremental data for a full billing month adds $0.40. CPU is derived from memory by the platform; choose a tier that fits your workload.

Understand storage billing →

Before migrating from PaperPod

  1. Export required memory files, session files and outputs, then inventory process/preview, browser and model tool dependencies.
  2. Port compatible execution, files, credentials and networking, and supply the browser/model or memory services the agent still needs.
  3. Validate system-state reuse across tasks, online RootFS growth, paused file access, session/reset behavior and all operation/model charges.

Common questions

Is Sandbox0 a drop-in PaperPod replacement?

Evaluate API compatibility and product scope. A shared sandbox category does not make SDKs, lifecycle semantics, or limits interchangeable.

Does keeping files also keep a running agent?

Filesystem state and volatile process state are separate. Sandbox0 requires explicit compatible memory checkpoints to preserve running processes; its default filesystem resume starts fresh processes.

Sources and review scope

The Boat team's Battleships directory is the discovery source. References below describe the product and plan discussed on this page. Check current availability, regional terms and billing units before migrating. Where the cited material does not establish a capability or price, the comparison identifies that uncertainty.

Related comparisons