Development environments / Capy alternative

A Capy alternative for the agent computer you operate

Capy is a coding-agent product with managed threads, machine access, model connections, and shared Drive state. Its VM disk survives ordinary sleep, but a rebuild can discard unpushed edits and installed packages. Compare the full agent workflow separately from the infrastructure that runs it.

Start buildingCompare capabilities ↓

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

When Capy fits

Choose Capy for its managed coding-agent experience, threads and subagents, review workflows, desktop access, and model/subscription connections. If those application features are central, a runtime API alone will not replace them.

When to consider Sandbox0

Consider Sandbox0 when you are building or operating the agent application and need a durable complete writable RootFS, automatic online growth, and supported file access during compute pauses. You supply the agent harness and surrounding coding workflow.

Capabilities

Capy and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeCapyBackground commands have a six-hour timeout and keep the machine awake only while the agent waits. Detached services alone do not prevent sleep; saved Drive artifacts have a separate lifecycle.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 filesCapyVM disk survives ordinary sleep, with documented rebuild data loss and deletion after 30 sleeping days; important artifacts should be pushed or saved in Drive.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSCapyOrdinary sleep retains the VM disk including installed state, but rebuild is a different boundary and can discard it.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 stateCapySleep/wake retains disk but stops processes, memory, and connections.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateCapyThe machine guide explicitly says sleep does not preserve memory or 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.

Capy exposes machine sizes with fixed disk tiers and setup/snapshot rebuild workflows. The reviewed guide does not establish automatic online complete-RootFS growth as the active agent fills its disk.

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 →

A sleeping disk and an independently saved artifact have different durability

Capy retains disk through ordinary sleep but stops memory, processes, and connections. Its guide warns that a failed resume or rebuild can lose unpushed work, installed packages, and scratch files; sleeping machines are deleted after 30 days. Pushed commits and intentionally saved Drive files are separate retained artifacts, so define where important work must be saved.

Source 1 ↗Source 2 ↗

A background command does not create an unlimited running machine

Capy background commands have a maximum six-hour timeout and only hold the machine awake while the agent waits on them. Detached services alone do not prevent sleep. Keep-awake controls, visible access, credits, and plan memory capacity also affect runtime. Split longer workflows and save progress instead of assuming waking continues the stopped process.

Source 1 ↗

Machine credits and model connections are distinct meters

Cloud machine time uses Capy credits even when model tokens use the user’s own key or subscription. Awake time is prorated, plus a two-minute wind-down each time a machine sleeps; sleep itself has no machine charge. Plans supply shared credits rather than removing machine usage, and aggregate awake-memory limits constrain concurrent threads.

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.

Capy

Pricing reviewed 2026-10-18

Small cloud machine
$0.10 per awake hour
1 vCPU, 4 GB RAM, 64 GB disk.
Rate source ↗
Large default cloud machine
$0.40 per awake hour
4 vCPU, 16 GB RAM, 64 GB disk.
Rate source ↗
Sleep wind-down
Two additional billed minutes per sleep
Rate source ↗
Lite monthly plan
$20 per month for $20 credits
Annual billing is a separate upfront commitment; purchased balance without a plan is also documented.
Rate source ↗
Pro monthly plan
$100 per month for $105 credits
Machine and applicable model/image charges share the organization balance.
Rate source ↗

Sleeping machines cost no machine time, but the wind-down is billed. Credits are an allowance spent on usage, not an additional equal-sized flat fee to double-count. Account memory limits, available sizes, model charges, and saved artifact limits affect the effective cost. No feature-equivalent managed-agent replacement or hardware-throughput claim is made.

Check current Capy 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 Capy

  1. Push or export required work and Drive files, and inventory setup/startup scripts, model connections, agent workflow features, and system changes that may be lost on rebuild.
  2. Recreate CPU-compatible tools in a Sandbox0 template and supply an agent harness, command/file integration, credentials, and UI/workflow behavior your product needs.
  3. Validate repeated system changes, growing data, paused file operations, lifecycle and command policies, and costs for runtime, storage, model use, and orchestration.

Common questions

Is Sandbox0 a drop-in Capy 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 ↗docs.capy.ai/machines ↗docs.capy.ai/drive ↗docs.capy.ai/models-and-pricing ↗Sandbox0 RootFS capacity →

Related comparisons

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