Development environments / Amp Orbs alternative

Amp Orbs alternative

Amp Orbs are remote machines attached to Amp agent threads. They keep code, tools and services available across thread work, and Amp prepares reusable project snapshots. The agent application, selected orb size and rules that wake compute all affect the comparison with a runtime you integrate yourself.

Start buildingCompare capabilities ↓

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

When Amp Orbs fits

Amp fits teams that want integrated coding-agent threads, remote development machines, terminals, files, desktop tools and portals in one application. Existing project setup and shared team workflows can reduce the surrounding product work.

When to consider Sandbox0

Consider Sandbox0 when your agent stack needs a whole durable RootFS that grows online beyond the initial filesystem size and supported file operations without waking compute. You still need the agent/UI, model routing, project setup and portal/application layer.

Capabilities

Amp Orbs and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeAmp OrbsIdle pause uses the later of five minutes without agent work and twenty minutes without interaction. That idle policy is separate from a maximum active lifetime.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 filesAmp OrbsThe orb thread retains files and services across ordinary pause/wake according to the overview.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSAmp OrbsPrepared snapshots capture installed software, but a general whole-RootFS retention contract for arbitrary state across all recovery paths is not established.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 stateAmp OrbsIdle pause and interaction-triggered wake are documented, with paused-orb compute costing nothing.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateAmp OrbsPrepared project snapshots are documented; arbitrary process-memory restore on every wake is not established.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.

Amp documents installed-software snapshots and ordinary thread persistence, which are real features. Each current size lists 60 GB disk; the reviewed docs do not establish automatic online RootFS expansion beyond that capacity. Sandbox0 can grow its mounted RootFS without restarting the running agent on growth-enabled templates.

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.

Amp documents file/tool interactions as activity that wakes a paused orb and starts an interaction window. The reviewed Files experience does not establish the same whole-RootFS read/write access while compute stays paused as Sandbox0’s Files API.

See paused file operations →

Project snapshots include installed software

The customization guide says prepared snapshots contain the repository and changes made by .agents/setup, including installed tools. A matching snapshot can be reused for up to 72 hours, and changing the setup script alone does not invalidate it. This is useful environment reuse; it differs from treating every future task as the same continuously accumulated computer.

Source 1 ↗

Idle closure depends on both work and interaction

An orb pauses when agent work has stopped for five minutes and interaction for 20 minutes, whichever deadline is later. Running a test is work; a leftover dev server alone does not keep it awake. Authorized portal requests and Files/Terminal/Desktop interactions can wake a paused orb and restart the billing window. Saver Mode avoids waking merely by opening a thread.

Source 1 ↗

Size, allowance and model usage are different meters

Current sizes all list 60 GB disk, with CPU/memory-dependent hourly rates billed by the minute. Paid tiers have a separate orb allowance, and larger sizes consume it faster. Model/tool usage has its own routing and credit rules; do not convert advertised orbin-time minutes into the same physical runtime for every size.

Source 1 ↗Source 2 ↗

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.

Amp Orbs

Pricing reviewed 2026-10-18

a1.tiny
$0.08/hour; 1 CPU, 2 GB memory
60 GB disk; runtime is billed by the minute.
Rate source ↗
a1.small
$0.17/hour; 2 CPUs, 4 GB memory
The same listed disk capacity, with a different compute size.
Rate source ↗
a1.medium
$0.33/hour; 4 CPUs, 8 GB memory
60 GB disk in the current size table.
Rate source ↗
Individual Megawatt
$20/month
The current card advertises 45,000 orbin-time minutes; resource-size weighting and other usage remain relevant.
Rate source ↗
Paused orb compute
$0
Opening a portal or interacting with files/tools may wake it and resume charges.
Rate source ↗

Keep standard resource rates separate from subscription allowance and model/tool usage. Included monthly usage does not roll over according to the pricing guide; purchased credits have separate expiry rules. A 72-hour reusable project snapshot is a preparation/cache lifetime, not a promise that a user’s live thread or files are deleted then.

Check current Amp Orbs 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 Amp Orbs

  1. Record orb sizes, thread state, setup/resume scripts, snapshot reuse, portals and activity that triggers wake/billing.
  2. Port compatible agent tools and repository setup to a Sandbox0 template, retaining or rebuilding the needed agent/UI, model and portal integrations.
  3. Test installed-tool retention, process restart handling, RootFS growth, paused files and actual resource plus model/application cost.

Common questions

Is Sandbox0 a drop-in Amp Orbs replacement?

Evaluate API compatibility and product scope. These products serve different core workflows, so a change may require a different architecture.

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.

Battleships research record ↗ampcode.com/docs/orbs/customizing ↗ampcode.com/docs/orbs/sizes-and-costs ↗ampcode.com/docs/pricing ↗ampcode.com/docs/orbs ↗Sandbox0 RootFS capacity →

Related comparisons

Agency Tool Company vs Sandbox0 →Bitrise RDE vs Sandbox0 →boxes.dev vs Sandbox0 →Capy vs Sandbox0 →Claw 2 Agent vs Sandbox0 →Clusy vs Sandbox0 →