Agent sandboxes / Tensorlake Sandboxes alternative

Compare Tensorlake sandboxes and Sandbox0 for long-lived agents

Tensorlake supports named sandboxes with state-preserving suspend/resume and filesystem or memory snapshots. Its current SDK also documents live root-disk resizing for CAS sandboxes. Compare those supported modes and billing conditions with automatic filesystem growth.

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

When Tensorlake Sandboxes fits

Tensorlake fits teams using its microVM sandboxes alongside serverless orchestration, snapshot cloning, GPU workflows, or private compute options. Choose named sandboxes for in-place suspend/resume; ephemeral sandboxes have a different lifecycle.

When to consider Sandbox0

Consider Sandbox0 when automatic growth of one durable writable RootFS and persistent file operations during compute pauses are the central needs. Its configured-memory compute meter and incremental storage meter offer a different cost model.

Capabilities

Tensorlake Sandboxes and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeTensorlake SandboxesFree and Usage Credits publish 2-hour and 24-hour session figures; Pro and Enterprise list unlimited duration, with lifecycle and idle policies still relevant.View evidence ↗Sandbox0ttl 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 filesTensorlake SandboxesNamed sandboxes preserve state through suspend; reusable snapshots have an independent lifecycle.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSTensorlake SandboxesFilesystem snapshots retain the environment; memory snapshots also capture processes.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 stateTensorlake SandboxesNamed sandboxes suspend and resume under the same ID.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateTensorlake SandboxesExplicit memory checkpoint type restores filesystem, RAM, and running processes.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.

Tensorlake CAS sandboxes can grow their root disk through an explicit live update on supported configurations. Sandbox0’s enabled RootFS expands automatically as free space runs low; compare the trigger and effective backend and plan ceilings.

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 →

Name the environment when it needs to return

Tensorlake named sandboxes can suspend and resume under the same identity. A snapshot instead creates a reusable artifact for another sandbox. Filesystem checkpoints are the default snapshot type; memory checkpoints must be requested when the agent needs its live process state.

Live resizing depends on the image backend

The current Tensorlake SDK documents live CPU, RAM, and root-disk updates for running CPU-only CAS sandboxes, and root-disk growth for GPU CAS sandboxes. Non-CAS sandboxes do not support live resize. Check that backend instead of treating the older fixed-resource lifecycle description as universal.

Pro includes usage at a different rate set

Tensorlake Pro costs $250 per monthly cycle and includes $250 of usage at Pro resource rates. Usage Credits use higher resource rates and a prepaid balance. Active CPU can fall back to allocated-vCPU time when a trustworthy sample is unavailable; RAM and disk are allocation-based while running.

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.

Tensorlake Sandboxes

Pricing reviewed 2026-10-18

Usage Credits active CPU
$0.07 per core-hour
Rate source ↗
Usage Credits RAM
$0.015 per GB-hour
Rate source ↗
Usage Credits root disk
$0.0002 per GB-hour
Rate source ↗
Pro subscription
$250/month including 25,000 CU
1 CU is $0.01. Pro rates are $0.042/core-hour, $0.009/GB-hour RAM, and $0.0001/GB-hour root disk.
Rate source ↗
Snapshot storage
$0.07 per GB-month
The published storage conversion uses a 30-day month.
Rate source ↗

Runtime is measured by the second and usage pooled in whole CUs. CPU falls back to allocated-vCPU time when active metering is unavailable. Pro overage follows its included CUs; prepaid Usage Credits stop new activity at zero balance rather than adding postpaid overage.

Check current Tensorlake Sandboxes 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 Tensorlake Sandboxes

  1. Identify named versus ephemeral sandboxes, CAS versus non-CAS images, checkpoint type, and independently mounted data.
  2. Translate image builds, orchestration hooks, network policy, idle behavior, and public endpoint handling.
  3. Test live data growth and both filesystem-only and required memory restoration, then compare costs after Pro included usage and CPU-meter fallback.

Common questions

Is Sandbox0 a drop-in Tensorlake Sandboxes 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