Amulet vs s3fs
Bucket-mount adapters like s3fs are free and genuinely useful for streaming large objects in and out of S3. They inherit object storage's weaknesses everywhere else: every metadata operation is an API round trip, renames are copies, small-file workloads crawl, and concurrent writers silently overwrite each other. Amulet is at least 2× faster across small-file operations and adds what a mount adapter can't: instant zero-copy forks, commit history with provenance, and conflict-safe publishing. Use s3fs to peek into a bucket; use Amulet when the filesystem is where work actually happens.
Amulet
Amulet is a high-performance file system for parallel AI workloads: workspaces mount in under 100 ms, fork instantly without copying data, and keep a versioned, attributable history of every change.
s3fs
s3fs (with cousins goofys and AWS Mountpoint for S3) is a FUSE adapter that presents an S3 bucket as a local filesystem, translating file operations into object requests.
Capability by capability
Capability
Amulet
s3fs
Small-file performance
Amulet
Yes
At least 2× faster than s3fs across small-file create, stat, read, list, and delete — the operations agent workloads live on.
s3fs
No
Every operation is one or more S3 API calls; metadata-heavy workloads (Git, npm install, grep) are notoriously slow.
Rename and directory semantics
Amulet
Yes
Real filesystem namespace with normal rename behavior for supported workflows.
s3fs
No
S3 has no rename — moving a file is a server-side copy and delete; directory renames are O(n) copies.
Instant copy-on-write forks
Amulet
Yes
Fork a workspace in milliseconds; zero bytes copied until writes diverge.
s3fs
No
Copying a prefix means copying every object.
Version history
Amulet
Yes
Content-addressed commits capture the full workspace; restore any revision exactly.
s3fs
Partial
S3 object versioning tracks individual objects, not a consistent snapshot of a working tree.
Conflict-safe publishing
Amulet
Yes
Compare-and-swap publishes; a stale writer gets an explicit conflict instead of silently overwriting.
s3fs
No
Concurrent writers are last-writer-wins per object; partial overwrites of a tree are possible.
Provenance
Amulet
Yes
Every commit records the actor, session, and run that produced it.
s3fs
No
Bucket access logs at best.
Durability of in-progress work
Amulet
Yes
Sessions persist across sandbox and VM restarts; published commits are immutable and integrity-checked.
s3fs
Partial
Objects are durable once fully uploaded; files buffered locally by the adapter can be lost with the instance.
Credential model
Amulet
Yes
Agents receive short-lived, workspace-scoped grants; S3 credentials never enter the agent process.
s3fs
No
The mounting process holds bucket credentials — every agent on the box effectively has your S3 keys.
Price of the software
Amulet
Partial
Managed service: $0.20/GiB-month for actively used data, 10 GB free.
s3fs
Yes
Free and open source — you pay S3 storage and, at volume, significant per-request API charges.
Setup
Amulet
Yes
Create a workspace by API and mount; no bucket layout or tuning.
s3fs
Yes
One binary and a bucket; simplicity is the point.
When to choose s3fs
- You need occasional, read-mostly access to an existing bucket and can tolerate object-storage semantics.
- You're streaming large sequential objects where Mountpoint for S3 performs respectably.
- Zero budget and zero new services is the constraint that matters.
When to choose Amulet
- Small files and metadata operations dominate — code, Git, JSON, package installs — where bucket adapters are slowest.
- Multiple agents write concurrently and silent last-writer-wins is unacceptable.
- You need per-environment forks of shared data without paying to copy it.
- You need history and attribution for what your agents produce.
- Agents must never hold S3 credentials.
Frequently asked questions
How much faster is Amulet than s3fs?
Amulet's release bar is at least 2× the operations per second of s3fs, as a geometric mean across small-file create, stat, read, list, and delete — and never slower in any primary agent workflow. The gap is architectural: s3fs turns each filesystem operation into S3 API round trips, while Amulet serves hot data from a local NVMe cache with p99 reads of 1.9 ms.
What about Mountpoint for S3 or goofys instead of s3fs?
Mountpoint for S3 and goofys make different trade-offs than s3fs — generally faster for large sequential reads by dropping even more POSIX behavior (Mountpoint doesn't support renames or appends at all). None of the bucket adapters change the underlying model: object semantics, per-request charges, no forks, no history, and last-writer-wins for concurrent writers.
s3fs is free — why pay for Amulet?
If a bucket-as-folder view is all you need, s3fs is the right price. The cost shows up at volume: S3 bills per request, so metadata-heavy workloads generate real API spend, and engineer or agent time lost to slow and semantically surprising filesystem behavior is the larger bill. Amulet's $0.20 per GiB-month of actively used data includes the requests, the performance, and the versioning — with 10 GB free to verify the difference.
Can agents share a bucket safely through s3fs?
Not really. Concurrent writers through bucket adapters are last-writer-wins per object, with no way to detect that another agent published first, and every agent process effectively holds the bucket credentials. Amulet gives each agent an isolated session with short-lived scoped credentials, and publishing is compare-and-swap — a stale publish fails loudly instead of destroying work.