Overview

AI agents do their best work on a filesystem. Coding agents like Claude Code and OpenCode spend most of their tool calls on read, glob, and grep, and almost any agent you write reaches for fs.readFile before it reaches for a database. The problem is where that filesystem lives: a local disk belongs to one machine, and the machines agents run on are increasingly disposable.

Tonbo Artifacts gives your agents a workspace that mounts as a regular Linux directory. The agent keeps using plain file operations. The workspace persists after the sandbox is gone, stays in sync across every machine that mounts it, and stores its data in S3 (ours by default, or your own bucket).

# Install once in your VM or container image, then run anywhere
curl -fsSL https://artifacts.tonbo.dev/install.sh | bash
artifacts workspace create my-workspace /mnt/work   # creates "my-workspace", mounts it
cd /mnt/work && claude

When you need this

Every server already has a disk. These are the situations where the disk stops being the answer.

The sandbox is disposable; the agent's work isn't

Sandbox VMs, CI runners, and serverless machines are built to be torn down, and everything the agent wrote to local disk goes with them. So you end up writing copy-in/copy-out glue around every run. With a mounted workspace, outputs and intermediate state are durable the moment they're written; the next run mounts the same workspace and picks up where the last one stopped. Start with the Quickstart.

More than one machine needs the same files, live

The agent writes in its sandbox while your editor reads on your laptop. Ten workers fan out over one dataset. An ingestion daemon writes while an analyzer reads. Syncing copies through S3 or rsync turns your agent loop into a sync engine. Every mount of the same workspace sees the same files, writes appear on other machines within tens of milliseconds, and flock works across hosts. See Share files across machines.

The data lives in S3, but your agent speaks files

Your corpus sits in a bucket; grep -r doesn't take an S3 URL. Downloading the bucket at boot makes cold starts scale with dataset size, and rewriting the agent against an object-store SDK means touching code that already works. A workspace presents that data as files and pulls content on demand. Agent traffic is dominated by stat, readdir, and open, which is exactly the path that generic S3 mounts are slow on and this one is built for. See Import data and Performance. If the data must stay in a bucket you control, bring your own bucket; credentials never leave your hosts.

You provision storage for your customers' agents

You run a sandbox or agent platform, every customer task needs isolated storage, and your platform credentials must never enter a customer-facing runtime. Tenants, per-runtime grants, and short-lived signed mount tickets are the primary API shape here, not a bolt-on. See the Quickstart for platform users.

When a local disk is still the right answer

• The agent runs on one durable machine and nothing needs to outlive it or be shared. Use the disk; archive to S3 if you want backups.
• The workload is streaming multi-GB sequential reads of a few large files (media processing, model weights). A direct S3 client with ranged reads beats any general-purpose filesystem, including this one.
• You need a native mount on macOS or Windows. v0 mounts on Linux x86_64 only; a Mac can still stage data in.

What your agent sees

A regular directory. ls, grep -r, fs.readFile, Claude Code, OpenCode, and anything else that opens files works against /mnt/work unchanged. There is no SDK in the agent's code, and the agent doesn't need to know Tonbo Artifacts exists. Under the hood it's a real kernel mount served by the artifacts CLI; how that works, and what it costs, is in Architecture and Performance.

Get started