Benchmarks

What does a persistent agent disk actually cost? Measured against an ephemeral one

Every plori agent gets its own disk that survives sleeping, waking, and the machine underneath being replaced. That is not free. We measured what it costs against the ephemeral container filesystem sitting in the same pod, on the same node, in the same minutes. The short answer: the cost is metadata, not bandwidth. Sequential writes stay within 4.8x, while deleting a tree of small files is 117.8x slower.

Measured 2026-07-25 against production · 5 rounds · 200 files of 4,096 bytes per round

The numbers.

§01

Small-file operations on the persistent disk versus the ephemeral filesystem: median, min and max across five rounds
Operation	Persistent disk	Ephemeral filesystem	Persistent is
Create 200 files of 4 KiB the npm install / git clone shape	115.2 files/s 104.2 to 124	1161.8 files/s 870.4 to 1217.5	10.1x slower
Walk and stat those 200 files find . -type f, the ls -R shape	69.1 ms 61 to 84.5	4.6 ms 4 to 5.1	15x slower
Delete those 200 files rm -rf of the same tree	812.5 ms 699.3 to 935.2	6.9 ms 6.5 to 7.2	117.8x slower
Sequential write, 1024 MiB, durable dd conv=fsync plus an explicit sync, wall-timed around both	196.9 MB/s	953.8 MB/s	4.8x slower

Read the spread, not just the median. Five rounds is enough to show that the small-file numbers are stable and not enough to publish a percentile, so the table gives the middle value and the whole range instead of a p90 that would be theatre at n=5.

Why metadata is the expensive part.

§02

The ephemeral filesystem is a local disk: a file create is a write to a journal a few centimetres away. The persistent disk keeps data in object storage and metadata in a networked index, so every create, rename, stat and unlink is a round trip. Bulk bytes amortise that cost across a large payload, which is why a 1024 MiB write stays within 4.8x. Two hundred four-kilobyte files cannot amortise anything, which is why the same hardware is 117.8x slower at deleting them.

The practical consequence is specific rather than general: dependency installs and large tree deletions are the slow operations, not your build output and not your data files. If your agent runs npm install on every turn, that is the thing to cache, and it is the thing a persistent disk lets you cache once instead of paying for on every cold sandbox.

That is the trade this page exists to state plainly. An ephemeral sandbox wins every row of the table above and then throws your work away. A persistent disk loses those rows once and then keeps the result, which is the entire reason plori has one.

What you get for it.

§03

The table above is the price. This is the thing being bought, measured the only way that means anything: we wrote a 256 MiB file, let the agent fall asleep until its machine was reclaimed, and then read the file back on the next turn.

The agent woke onto a different pod. The file was still there, and its MD5 was byte-for-byte identical to what was written before the machine went away. No copy step, no restore, no snapshot: the disk simply outlived the computer.

cold read, first touch on the new machine: 16.3 MB/s (15.74 s for 256 MiB)

warm re-read, same bytes again: 16.7 MB/s (15.3 s)

Note that the warm re-read is no faster than the cold one. At this size the bytes are not being served from a local cache in any meaningful way, so 16.3 MB/s is what a large sequential read costs on a woken agent, not a first-time penalty that disappears afterwards. That is a slower number than the write path and we would rather state it than let a reader assume the second read is free.

What we measured and threw away.

§04

Two of the metrics we collected did not survive scrutiny. They are in the raw data because we published everything we ran, and they are excluded from the table above because we could not defend them. A benchmark that only reports the numbers that worked is not a benchmark.

seq_write_mbps (per-round, 64 MiB)

Round 1 measured 28.6 MB/s on the persistent tier and rounds 2-5 measured 306-351 MB/s. A 12x spread across identical rounds is the client write buffer warming up, not the disk. conv=fsync does not force a network filesystem to flush all the way to object storage, so this figure is not durable-write throughput and is not reported as such. The size sweep below replaces it.

seq_read_direct_mbps / seq_read_warm_mbps

On the persistent tier the O_DIRECT read measured ~103 MB/s and the warm read that followed it measured ~13 MB/s. A cache-bypassing read cannot legitimately be 8x faster than a cached one, so at least one of the two is measuring something other than what its name says. Both are discarded rather than explained away; the cold-read-after-wake figure is the honest read number and it is measured a completely different way.

Method.

§05

One production agent on plori's live cluster (Vultr sea region), measured from inside the agent's own shell. persistent = /workspace, the agent's orlop FUSE disk (object storage for data, Redis for metadata). ephemeral = /tmp, the container's writable layer on the node's local ext4. Same pod, same node, same minutes, so the two tiers differ only in what backs them.

Both tiers are measured from inside the same running agent, back to back, by scripts/bench/disk-sample.sh. Nothing is simulated and no separate benchmark host is involved: the numbers are what the agent’s own shell experiences, which is the surface a user actually has.

Small-file timings are wall-clocked with date +%s%N around the whole loop and include an explicit sync. Sequential writes use dd conv=fsync plus a following sync, wall-timed around both. dd conv=fsync followed by an explicit sync, wall-timed around both. Swept 64/256/1024 MiB specifically to outrun the client write buffer that made the per-round figure meaningless; the 1 GiB row is the one the report quotes, because it is the only size where the buffer cannot hide the network.

The tooling is deliberately dd and shell arithmetic rather than fio: installing a benchmark toolchain into the image would change the image being measured.

Limitations.

§06

One agent, one node, one day. This is a single machine on 2026-07-25, not a fleet distribution. A busier node, a different instance type, or a different object-storage region will move these numbers. Treat the ratios as the finding and the absolute values as one observation.
n=5. Enough to show stability, not enough for percentiles. The min and max are published for every row precisely so nobody has to take the median on trust.
The ephemeral tier is not a competitor’s sandbox. It is the container filesystem in our own pod. It stands in for what any ephemeral sandbox gives you, which makes it a fair floor for “local disk, gone when the container dies”, but it is not a measurement of any named product.
sync is filesystem-wide. In a container it flushes more than our file, so the durable-write figure is a conservative upper bound on the time to durability, not a lower one.

Raw data.

§07

Every sample behind this page, including the discarded metrics, published under CC BY 4.0. Re-derive the table with python3 scripts/bench/disk-analyze.py.

data.csv data.json