Why Sandbox0 Is a Good Fit for Personal Agent Cloud Computers

Personal agents are getting their own computers.

Grok Bot gives a user's Bots a shared, persistent cloud computer with a browser, filesystem, and terminal. Meta Muse runs on a dedicated secure virtual machine. OpenAI dots have their own cloud computer and browser, with files, software, and browser sessions that can remain available between periods of use.

The allocation models differ: several agents can share a user's computer, or a product can give separate agents separate environments. The common requirement is a place where an agent can install software, use websites, run programs, and keep the results for its next task.

For the companies building these products, that creates an infrastructure question: how do you give every user a lasting computer at a cost that works as the user base grows?

Sandbox0 addresses that question by separating the environment an agent keeps from the compute it uses. Its writable root filesystem persists, grows online, and can be attached to fresh compute without copying every accumulated byte.

Consider a personal agent that helps someone run a small business. On Monday, it installs a document-processing tool and organizes invoices. On Tuesday, it downloads sales records and builds an analysis. A month later, it has scripts, package caches, local indexes, generated reports, and a collection of tools configured for that user.

Those files live throughout the system. A tool may install under /usr/local, configuration may live under /etc, and user data may spread across the home directory and workspace. Preserving that environment lets the agent reuse the setup it has already done.

Sandbox0 retains the whole writable root filesystem across successful checkpoints. Installed software, configuration, dependencies, and user files can survive a pause and return with the same sandbox identity. Runtime-only mounts such as /tmp remain temporary; durable data belongs on the RootFS. The filesystem documentation describes that boundary.

As the agent keeps working, its storage needs change. Choosing a large fixed disk for every new user leaves unused capacity. Choosing a small one creates a future expansion job, potentially in the middle of useful work. Different users also accumulate very different amounts of data.

Sandbox0's growth-enabled image imports start with a smaller filesystem inside a larger sparse device. When free space runs low, the filesystem grows online, within the device's configured ceiling. The agent keeps its running processes, paths, and open files through that expansion.

The supported sparse device ceiling is 64 TiB. Empty address space does not reserve an equivalent amount of physical storage. This is a capacity ceiling, rather than a claim about full-capacity performance, and existing images and snapshots keep their captured geometry. Our RootFS growth article explains the implementation and qualification results.

Sparse capacity alone would still leave a worker with an ever-growing local disk as the agent writes data. Sandbox0 also publishes changed blocks to regional object storage in the background. After a commit is acknowledged, the worker can reclaim the local write-log records covered by that commit. Worker caches and write logs have their own bounded budgets, separate from the agent's accumulated durable data. Storage throughput still matters: slow uploads or an outage can cause writes to wait when those budgets fill.

This combination lets the environment grow over time without requiring its compute worker to hold a complete local copy of everything the agent has ever saved.

Compute has a different usage pattern. A personal agent might prepare a morning brief, process a document after lunch, and reconcile expenses in the evening. Between those jobs, it may wait for a message, a scheduled task, or a person's approval. Keeping CPU and memory allocated through every gap can turn a growing population of retained environments into a growing population of idle computers.

Sandbox0 can pause a sandbox, preserve its committed filesystem, and release its runtime compute. When work returns, it resumes the same sandbox identity on available compute. The product's scheduler or event handler can remain outside the paused sandbox and wake it for the next job; supported inbound access paths can also trigger automatic resume. A paused process cannot keep monitoring events on its own.

The next question is what happens after months of accumulated files. If each pause uploaded the entire disk and each resume downloaded it again, frequent pausing would become increasingly expensive as the environment grew.

Sandbox0 uses incremental checkpoints and demand reads. Checkpoints publish the writable branch's changes and reuse unchanged blocks. Resume attaches the committed filesystem generation and fetches blocks as the workload reads them. Execution can start without first downloading the whole RootFS. See pause and resume.

For example, an agent might have accumulated 100 GiB of data while its next task needs only a few tools and a handful of documents. Those historical 100 GiB do not all need to move before that task can begin. Pause and resume still take time: outstanding writes, metadata, cache state, storage access, and the task's read working set affect latency. The benefit is removing the mandatory full-filesystem copy from each lifecycle operation.

File persistence also has a different cost and continuity model from keeping a live process. Default pause/resume preserves the filesystem and starts fresh processes. A resumable agent harness can continue from its saved task state. Explicit, experimental memory checkpoints can retain supported process state on compatible restores, with additional capture and restore work based on execution-state size. Existing network connections are not guaranteed to survive. Choose the mode that fits the task's continuity requirements.

The economics become easier to see with a simple example. As of October 17, 2026, Sandbox0 Cloud compute costs $0.015 per GiB-hour, billed by the second using the configured memory limit. Persistent RootFS, snapshots, retained memory checkpoints, and paused sandboxes are free under the current pricing. Each team can retain 2,000 paused sandboxes by default and request a higher quota for free, subject to approval.

Suppose a sandbox has 2 GiB of configured memory over a 30-day month:

Both rows use the same Sandbox0 rate: 2 GiB × running hours × $0.015. The second assumes all startup, execution, and checkpoint activity fits inside those 30 running hours. It is an illustrative usage calculation, not a measured workload or a comparison with another provider's internal costs. Model inference and external services are separate. A sandbox left running while idle still accrues compute charges.

For a personal agent product with many intermittently active users, retained environments and concurrent compute demand can therefore be planned separately. Storage growth does not require matching local disk reservations, and returning to an older environment does not require a full disk download. The savings depend on the workload's actual running time and resource needs; continuously working agents still need continuous compute.

Sandbox0 gives a personal agent a computer it can keep coming back to: a persistent environment that grows with its work, with compute allocated when there is work to do.

Start building on Sandbox0 Cloud, or read the getting started guide to create your first sandbox.