Why we replaced JuiceFS: a 9,749-file checkout took 83.8 to 90.1 s under gVisor
Our agents needed their own copy of files and saved versions, not a live shared filesystem.
Our AI agents needed their own copy of the files and saved versions of it. They did not need a live filesystem shared over the network, and on September 30, 2026 we decided to replace JuiceFS.
The short answer
- JuiceFS patches reached four layers: the gVisor runtime, the JuiceFS client, Litestream and our mount supervisor. We tagged 48 versions of our JuiceFS fork between August 13 and September 29, 2026.
- Small files were slow on FUSE. A git checkout of 9,749 files took 0.78 s on a local directory and 83.8 to 90.1 s on a JuiceFS mount under gVisor.
- Workspaces replaced it. Each agent works on a local disk, and the platform saves a version every 60 seconds during a run and at the end.
Git checkout of 9,749 files
All cases ran on the same node with the same image, each FUSE case three times and the local case once.
| Where the checkout wrote | Time |
|---|---|
| Local directory, host kernel | 0.78 s |
| JuiceFS FUSE mount, host kernel, no gVisor | 39.7 to 43.5 s |
| JuiceFS FUSE mount, under gVisor | 83.8 to 90.1 s |
What we gave up
- Continuous replication: a crash can lose roughly the last minute of work, plus the time the save takes.
- Local disk size: unsaved work must fit on the server's local disk.
- Migration: moving existing agents off JuiceFS is a separate job, and it was not finished when we wrote the post.
The full post has the three storage changes we made in September 2026, the sharing gateway we designed, and three questions for anyone building agent storage.