Storage for agentsChapter 6 of 6
What Archil does, and where it falls short
The short answer
Archil gives each agent workspace one disk that any machine can mount, replicated across availability zones before fsync() returns, with checkpoints and branches in milliseconds at any size, billed for the data in use. It’s slower than Amazon EFS on large sequential writes, and shows other machines a new file only when their cache expires or they ask for it.
Hunter LeathFounder & CEO, Archil
8 min readChecked November 2026Read as Markdown
So far this guide has argued from the problem. This chapter is about what we built: what a team gets on the first day, in commands and measurements, and then where Archil is slower or narrower than you might need.
One disk through a day§
An Archil disk is a file system that any Linux machine can mount. You create it with one API call, and it stays put while the machines that use it come and go. Here is one agent’s day on one disk.
Five commands drive one Archil disk through an agent’s day. In sandbox A, archil mount myorg/work /work mounts the disk, and npm ci && npm test installs and tests a project. Each fsync() is replicated across availability zones before it returns. archil checkpoints create /work ready checkpoints the whole disk, and archil branches create makes three branches of that checkpoint, try-1 to try-3. Machines B, C, and D each mount one branch with archil mount --branch and carry on from the checkpoint. Sandbox A stops, and nothing it saved is lost. At the median, a mount took 50 ms, a checkpoint 13 ms, and a branch 33 ms, whatever the disk’s size.
Written out in full, the day is a handful of lines:
# Sandbox A: mount the disk and work in it.
sudo archil mount myorg/work /work --region aws-us-east-1
cd /work && npm ci && npm test
# Mark a point to return to, then fork it once per attempt.
archil checkpoints create /work ready
archil branches --region aws-us-east-1 create dsk-0123456789abcdef try-1 --from-checkpoint ready
# Machine B: mount the branch and carry on.
sudo archil mount myorg/work /work --region aws-us-east-1 --branch try-1Each step replaces a rung of the do-it-yourself ladder in The obvious ways to build it. The following table gives our medians, measured from a c7gn.2xlarge in AWS us-east-1.From Limits, which links the script that produced them.
| Step | Median | What it replaces |
|---|---|---|
archil mount | 50 ms | Downloading the workspace before the agent starts, or detaching a volume from one machine and attaching it to the next |
A 4 KiB write with O_SYNC | 2.0 ms, replicated across zones | An upload after the agent finishes, and the work lost if the machine dies first |
archil checkpoints create | 13 ms, at any size | A tarball of the workspace, uploaded in a time that grows with its size |
archil branches create | 33 ms, at any size | A full copy of the workspace for every attempt |
One disk takes up to 5,000 connected clients, so the next step can run on one machine or a fleet. Checkpoints and branches work on Archil-managed disks, the default. Copies and references shows why a pointer beats a copy at this scale.
Speed and safety, measured§
The day depends on two properties that usually trade against each other.
Speed comes from where the work happens. The machine that holds a checkout answers open(), write(), and rename() from its own memory, as a local disk does, and sends its changes to our servers about once a second. Where the truth lives explains how that stays correct when other machines share the disk. On one EC2 host, npm ci of 18,602 files, timed until every write was durable, took 12.4 s on Archil and 10.7 s on the instance’s own EBS volume.
Safety comes from what fsync() means. When it returns, the write is replicated across availability zones, and we design for 99.999% durability for recent writes before they reach S3. If a sandbox dies, every write that fsync() covered is on the disk. Writes the program never synced, and that the client hadn’t sent yet, can be lost, the way unsynced writes on a local machine are lost in a power cut.
A dead sandbox’s checkout doesn’t expire. Archil marks it orphaned, usually within a minute, but doesn’t release it. No other machine can write there until one takes it over with archil mount --force or archil checkout <path> --force. Taking it over discards the writes the old holder hadn’t sent, much as force-detaching an EBS volume skips its cache flush.From Forcing ownership and Release a stale lock in our docs. --force revokes every other client’s checkouts, including running ones. Revoking only orphaned checkouts through the SDK can’t interrupt a client that’s still connected.
We also benchmarked Archil against Amazon EFS, AWS’s managed NFS file system, from one host.The host, versions, and commands are in File systems on one host, and all 15 results are in Benchmark against Amazon EFS.
fsync().Nine of the 15 tests we ran against Amazon EFS, including all three that EFS won, from one c7gn.2xlarge in us-east-1 with Archil client v0.9.2, medians of 3 runs. Archil was faster on a git checkout of an old react tag (1.06 s against 46.9 s, 44 times), 10,000 SQLite transactions with synchronous=FULL (23.9 s against 523 s, 22 times), npm ci of create-next-app (7.6 s against 86.3 s, 11 times), a git clone of react (9.8 s against 81.5 s, 8.3 times), cold 4 KiB random reads (4,086 against 1,298 IOPS, 3.1 times), and cold sequential reads (1,197 against 1,020 MB/s, 1.2 times). EFS was faster on a bulk insert of 1 million SQLite rows in one transaction (1.7 s against 11.0 s, 6.5 times), 4 KiB random writes followed by fsync() (2,976 against 953 IOPS, 3.1 times), and a 4 GiB sequential write followed by fsync() (590 against 194 MB/s, 3.0 times).
Archil wins where agents spend their time: many small files, many metadata operations, and transactions that each wait for fsync(). EFS wins when one client writes a lot of data at once, which is the first item in Where Archil falls short.
Your bill and your bucket§
Archil bills for the data you use, not for a size you reserve. Data counts as active for about an hour after it’s read or written, and the whole of an Archil-managed disk also bills at a lower archive rate. Branches and checkpoints bill the data they share once. What you pay for gives the rates and works through what those meters do to the bill for a fleet of mostly idle agents.
A disk can instead sync to a bucket you own on S3, GCS, R2, or another S3-compatible store, on any paid plan. Each file lands as an ordinary object at its path, tens of seconds to minutes after it’s safe on Archil. DuckDB, Spark, or the AWS CLI can then read it without our software. You pay your provider for the bucket, and Archil for the data in use.
The agent writes events.parquet and calls fsync(). Archil replicates the write across availability zones, and then fsync() returns: the data is safe. Tens of seconds to minutes later, the object lands in your bucket at data/events.parquet, where DuckDB on any machine queries it with no Archil client or account.
Many machines on one disk§
Any number of machines can write one disk at once, including the same files. How they share it depends on the mode each one mounts in. Exclusive mode, the default, gives one client the whole disk, and other clients can mount it read-only. Shared mode leaves the disk read-only on every client until it runs archil checkout <path>, and opening or creating a file checks that file out automatically. Conditional mode lets any client write wherever nobody holds a checkout, at the speed of a remote file system, and the last write to reach the disk wins. In exclusive and shared mode, a second writer to a checked-out path gets an error instead of silently replacing the first writer’s work.
Shared mode, Change /data/report.csv: works, local speed. Nobody holds the file, so opening it for writing checks it out for B until B closes it.
Client A has checked out /repo (in exclusive mode, the whole disk). In exclusive mode, B mounts with --read-only: it can read everything, and every change fails as read-only until A unmounts. In shared mode, B can read, can’t change /repo/plan.md until A checks it in, can write a file nobody holds (opening it checks it out until B closes it), can’t delete a file until it checks out the parent directory, and writes at local speed after archil checkout /data. In conditional mode, B can read, changes and deletes outside /repo run on the server at remote-file-system speed with the last write winning, and a write to /repo/plan.md can return and then fail when it’s sent: B’s mount turns read-only and its unsent writes are lost.
For which mode fits a fan-out, a reviewer beside a writer, and a handoff, see Can many machines use it at once?
Where Archil falls short§
These are the limits we’d want to hear about before choosing storage, and what to do about each.
Large sequential writes are slower than on EFS. On a 4 GiB sequential write with fsync(), EFS wrote 590 MB/s and Archil 194 MB/s. We have more work to do on throughput. If your agents mostly write large files in one stream, such as model weights or dataset exports, time that workload on both before you choose.
A new file takes about 30 s to appear on another machine by default. Each client answers lookups from its cache until the entries expire, so a reader can miss a file that another machine created a moment ago. Have the reader run archil invalidate-cache on the mount before it reads. In our test, it then saw the new file in about 70 ms.
Managed disks use our internal format. The objects behind an Archil-managed disk can’t be read without Archil. Export them over the disk’s S3 API or by copying from a mount, or use a disk synced to your own bucket wherever other tools need the files.
You can’t delete individual branches or checkpoints today. Each one keeps the data it changed, on your bill, for as long as its disk exists. If your agents fan out many short-lived attempts, count what each attempt writes as storage you keep.
In our public regions, sandboxes and serverless tool calls run in AWS only. Disks in GCP us-central1 work for storage, but disk.exec there returns Exec is not enabled, and Archil sandboxes don’t run there. Create a disk in an AWS region if your agents will run commands through Archil, or mount it from your own compute.
How to evaluate us, and anyone else§
The measurements in this chapter can be checked. Our limits page links the script behind its latency figures, which you can run on your own account. The EFS benchmark lists its host, versions, and commands, including for the tests EFS won. Run the workload your agents actually run, timed until its writes are durable, on us and on anything else you’re considering.
Evaluating storage turns the argument of this guide into one page per buyer’s question, each with a test to run against any vendor. Its scorecard rates every architecture in this guide on those questions, Archil included, and each question’s page has the test that checks the rating.