Petabyte-scale storage for AI agent sandboxes

Celesto sandboxes include a large durable filesystem for workspace data. Your agent can write files, clone repositories, install packages, and generate artifacts without being limited by the VM root disk size. The root disk is durable too. It holds the operating system, runtime, and system-level state. CelestoFS is a separate durable workspace filesystem for the files your agent actively works with.

CelestoFS architecture showing an AI agent in a Celesto sandbox, the durable root disk, the CelestoFS workspace, and the managed storage plane

What you get

A large durable workspace filesystem for agent files and generated data.
Durable root disk and workspace state across stop and start.
Normal file operations from inside the sandbox.
A filesystem name that appears as celestofs in df -h.
A root disk size that can stay small even when workspace data is large.

Delete the computer when you no longer need its saved state. Deleting a computer removes its files, workspace data, and resources.

Check the filesystem

Run df -h inside a Celesto computer to see both storage surfaces. In Celesto Linux sandboxes, /home/ohm is the sandbox user’s home directory and the default place for agent workspace files.

CLI

celesto computer create --template coding-agent --disk-size-mb 10240
celesto computer run einstein "df -h / /home/ohm"

Example output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        10G  2.2G  7.8G  22% /
celestofs       1.0P  161M  1.0P   1% /home/ohm

/dev/root is the VM root disk. celestofs is the large workspace filesystem.

Prove the workspace can exceed root disk size

This test creates a 10 GiB sandbox, then writes 20 GiB of data into the workspace. It shows that large workspace data is not constrained by the root disk size.

This test writes real data and can take several minutes. Run it only in a test computer, then delete the computer when you are done.

CLI

celesto computer create --template coding-agent --disk-size-mb 10240

Write 20 GiB in the sandbox home directory:

CLI

celesto computer run einstein "python3 - <<'PY'
from pathlib import Path
import hashlib
import os

target_dir = Path('/home/ohm/storage-proof')
target_dir.mkdir(parents=True, exist_ok=True)
target = target_dir / 'twenty-gib.bin'

with target.open('wb') as f:
    for gib in range(20):
        for block_index in range(1024):
            seed = f'{gib}:{block_index}'.encode()
            block = hashlib.sha256(seed).digest() * 32768
            f.write(block)
        f.flush()
        os.fsync(f.fileno())
        print(f'wrote {gib + 1} GiB', flush=True)

print('final size bytes:', target.stat().st_size)
PY"

Verify the file is larger than the 10 GiB root disk:

CLI

celesto computer run einstein "du -h /home/ohm/storage-proof/twenty-gib.bin && df -h / /home/ohm"

You should see a 20 GiB file in the sandbox home directory while /dev/root remains a 10 GiB filesystem. That does not mean the root disk is temporary. It means workspace storage and root disk storage have different jobs. Clean up the proof data:

CLI

celesto computer run einstein "rm -rf /home/ohm/storage-proof"
celesto computer delete einstein

What survives stop and start

Files on the workspace survive stop and start:

CLI

celesto computer run einstein "echo saved > /home/ohm/state.txt"
celesto computer stop einstein

celesto computer start einstein
celesto computer run einstein "cat /home/ohm/state.txt"
# saved

Deleting the computer removes the saved computer state:

CLI

celesto computer delete einstein

Latest benchmark metrics

These numbers help you choose where to write files. CelestoFS is best for large durable workspace data. The root disk is still best for temporary scratch data with many tiny file updates. The tests ran inside a coding-agent Linux sandbox. The data source was a local HTTP server inside the same computer, so public internet bandwidth was not part of the measurement. The benchmark wrote to /home/ohm for CelestoFS and /tmp for root disk comparison.

These benchmarks are a snapshot from July 2026, not a performance guarantee. Results vary with machine size, cache state, file mix, and concurrency.

Many small files

This test writes 5,000 files, each 4 KiB, across 100 directories with 32 concurrent workers. p50 means median file latency. p95 means 95% of file writes completed at or below that latency.

Target	Write time	Throughput	p50 file latency	p95 file latency	Delete time
CelestoFS	13.974s	357.8 files/s	47.65ms	129.01ms	2.780s
Root disk	7.673s	651.7 files/s	4.15ms	7.09ms	0.072s

Root disk remains faster for high-churn tiny files. Use /tmp for throwaway scratch files that do not need to survive.

Large files

This test writes one file at each size: 10 MiB, 100 MiB, 500 MiB, and 1 GiB. Total data written is 1,634 MiB. Sync time is the time to run sync after all files are written.

Target	Write time	Write bandwidth	Sync time	Delete time
CelestoFS	7.835s	208.56 MiB/s	4.090s	0.358s
Root disk	7.072s	231.06 MiB/s	5.687s	0.144s

Per-file write results:

Target	10 MiB	100 MiB	500 MiB	1 GiB
CelestoFS	0.043s / 230.88 MiB/s	0.237s / 421.38 MiB/s	1.846s / 270.80 MiB/s	5.703s / 179.56 MiB/s
Root disk	0.015s / 674.62 MiB/s	0.086s / 1157.66 MiB/s	0.521s / 960.51 MiB/s	6.449s / 158.78 MiB/s

In this run, CelestoFS reached about 90% of root-disk aggregate write bandwidth: 208.56 MiB/s compared with 231.06 MiB/s. Large sequential files are a good fit for CelestoFS because they match the durable workspace use case: datasets, archives, browser traces, build outputs, reports, and model files.

Choose the right storage surface

Both root disk and CelestoFS are durable across normal computer lifecycle operations. Choose where to put data based on what the data is for.

Storage	What it is for	How to think about it
Root disk	Operating system, runtime, package manager internals, and system-level state.	Size it with `disk_size_mb` when system tools need more room.
CelestoFS workspace	Agent work, repositories, generated files, datasets, build artifacts, and project state.	Use it for large durable workspace files.

For most agent work, write project data to the sandbox home directory. Increase root disk size when the OS, package manager, or system-level tooling needs more room.

How it works

CelestoFS is mounted inside the sandbox so programs can use normal file operations from the guest. Celesto manages the storage lifecycle for you. You do not need to mount or configure anything yourself. Use the Celesto SDK or CLI, write files in the sandbox, and stop or start the computer when you want to resume the same work later.

Best practices

Write agent work under the sandbox home directory or the template workspace path.
Keep generated artifacts and repositories in the workspace, not under /tmp.
Stop a computer when you plan to resume it later.
Delete a computer when the saved computer state is no longer needed.
Use df -h / /home/ohm when debugging disk usage so you can see root disk and workspace storage separately.

Start Here

Features

Guides

Agents and Integrations

Petabyte-scale storage for AI agent sandboxes

What you get

Check the filesystem

Prove the workspace can exceed root disk size

What survives stop and start

Latest benchmark metrics

Many small files

Large files

Choose the right storage surface

How it works

Best practices

​What you get

​Check the filesystem

​Prove the workspace can exceed root disk size

​What survives stop and start

​Latest benchmark metrics

​Many small files

​Large files

​Choose the right storage surface

​How it works

​Best practices

What you get

Check the filesystem

Prove the workspace can exceed root disk size

What survives stop and start

Latest benchmark metrics

Many small files

Large files

Choose the right storage surface

How it works

Best practices