Development environments / Clusy alternative

Clusy alternative

Clusy is an AI notebook environment with CPU/GPU choices and saved kernel state. Its durable bundle can restore variables and workspace files after the live machine is gone. That is a meaningful continuity feature, with different scope and failure boundaries from retaining a complete Linux RootFS and arbitrary process execution.

Start building Compare capabilities ↓

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

When Clusy fits

Clusy fits notebook-centric analysis, model work and agent-assisted cells where integrated models, branching and GPU choices matter. Keep that notebook/kernel workflow if it is the desired application rather than treating it as a generic raw sandbox.

When to consider Sandbox0

Consider Sandbox0 when the agent needs installed system tools, configuration and growing files retained as a whole writable RootFS. You supply a compatible notebook/agent layer and model endpoint; GPU and specialized inference infrastructure need separate qualification and should not be assumed included.

Capabilities

Clusy and Sandbox0: what persists?

Feature comparison with documentation and verification status
Capability	Clusy	Sandbox0
Environment and runtime lifetime	ClusyNot established in this review	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 files	ClusyWorkspace files and notebook content survive through documented completed durability boundaries and can restore onto a rebuilt sandbox.View evidence ↗	Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFS	ClusyThe documented bundle covers workspace/namespace and best-effort package reinstallation, not an established full writable Linux RootFS image.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 state	ClusyCPU pause/resume and cold restoration from a durable bundle are documented; paused machine availability is not guaranteed.View evidence ↗	Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process state	ClusySelected kernel variables are serialized; arbitrary process memory, FDs, live connections and device contexts are not a documented checkpoint contract.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.

Clusy durably saves notebook namespaces and workspace files at boundaries and can rebuild a machine. That is not the same as a complete automatically growing Linux RootFS with system configuration retained in place. Its checkpoint quota should not be compared directly with Sandbox0’s logical filesystem-growth ceiling.

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.

Persisted notebook content and state bundles are accessible concepts in Clusy, but the reviewed docs do not establish arbitrary paused-Linux-RootFS read/write access. A new workspace file is also not durable until a completed boundary, so plan artifact publication explicitly.

See paused file operations →

Checkpoint boundaries determine what survives a crash

The state guide saves durable state when nobody remains connected and no agent run is active, or when hardware changes with Transfer state. It does not durably checkpoint after every cell. Abrupt machine loss can lose newer variables and workspace files; a newly forked branch is not durable until a later boundary.

Source 1 ↗

Serialized kernel state is narrower than a process image

Workspace files are restored from the bundle, and installed packages are recorded and reinstalled best-effort. Open files, active database connections and CUDA/device contexts cannot all be serialized. Each branch namespace checkpoint caps at 4 GiB; large objects can be written to workspace files and rebuilt instead.

Source 1 ↗Source 2 ↗

Machine retention and saved-state retention are different

The pricing page labels paid retention indefinite, but the state guide says paused sandboxes have no guaranteed plan-based retention period. Releasing a machine does not delete the notebook or durable bundle: reopening can cold-start and restore saved state. Do not translate a Free machine release after three days into a claim that all project data is deleted.

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.

Clusy

Pricing reviewed 2026-10-18

Free: $0/month; Auto model, 8 vCPU/8 GB CPU sandbox, 5 GB checkpoint storage and one concurrent sandbox; live-machine release differs from saved-data retention.; Rate source ↗
Plus: $12/month; 30 GB checkpoint storage, T4 GPU option, up to 16 GB RAM and three concurrent sandboxes.; Rate source ↗
Pro: $30/month; 3× Plus usage, 100 GB checkpoint storage, entry GPUs, 32 GB RAM and eight concurrent sandboxes.; Rate source ↗
Max: $90/month at 10× Plus; $200/month at 30×; Checkpoint allocations are 512 GB and 2 TB respectively; hardware/concurrency limits differ.; Rate source ↗

Usage multiples are relative to the Plus allowance, not a published universal GPU-hour or token conversion. Checkpoint-storage quota is different from a block-device capacity or the per-branch 4-GiB namespace cap. Current docs explain cold recovery and exclusions; do not assume an indefinite paid label guarantees that the same live machine and all RAM will remain available.

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

Inventory notebooks, branch checkpoints, workspace artifacts, package installs, unpicklable resources and actual GPU/model requirements.
Run compatible CPU notebook/agent code on Sandbox0 or keep Clusy’s notebook/GPU layer separately, preserving data and rebuilding required resources explicitly.
Test crash recovery and state scope, whole-RootFS tool retention, online growth, paused files and complete application/model/compute costs.

Common questions

Is Sandbox0 a drop-in Clusy 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.clusy.io/docs/concepts/state-persistence ↗docs.clusy.io/docs/reference/limits ↗www.clusy.io/pricing ↗Sandbox0 RootFS capacity →

Related comparisons

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