LayerFS 1.0: AI Agent Workspaces, Benchmarks and Deployment Limits

Ephemeral AI Lab released LayerFS 1.0.0 on October 21, 2026, a filesystem for coding agents that need separate writable workspaces over shared history. It moves beyond developer previews with a revised workspace API, but remains source-only and explicitly offers no crash or power-loss durability.

That combination makes it interesting infrastructure to evaluate, rather than something to put underneath your only copy of important work. The useful question is whether short-lived agent workspaces can reduce repeated setup without losing track of what each attempt changed.

How LayerFS workspaces work

LayerFS separates temporary working environments from committed file history. An agent gets a writable view, makes changes and commits them. Other attempts can start from shared history rather than making complete independent copies of every file.

The project also preserves ignored files in commits. That matters for dependencies and generated files that a normal Git checkout might leave behind. If several agents test alternative implementations, carrying the prepared environment with the workspace could avoid repeating installation for every attempt. How much time that saves depends on the project and its setup costs.

The versioned JavaScript SDK guide describes separate operations for branches, file access and mounted workspaces. File, branch and project Store calls execute inside the calling process. Shell commands run through a mounted workspace in a sandbox.

Those Store calls require Linux and a shared local Store on ext4, xfs or btrfs. The documented setup can use Docker Desktop on a Mac, but that is different from claiming the storage engine runs natively on any macOS filesystem.

What changed in LayerFS 1.0

The release notes replace the earlier sandbox-management API with workspace methods. LayerFS places workspaces into numbered sandboxes, starting another when existing ones each hold 16 workspaces. Idle sandboxes close after two minutes.

The release improves merging and storage reuse, removes the old command-output cap and adds a LayerFS interface inside DeepSeek Harness. Its JavaScript SDK now follows a major-version boundary for incompatible changes.

Migration is not transparent. Stores from version 0.1.7 or earlier are rejected and must be initialized again. The SDK, native addon and daemon must come from the matching release tag. There is no published npm package, prebuilt binary or public image for this release.

For an infrastructure team, that means budgeting for a source build and a disposable evaluation project before trying to integrate it into an existing agent runner.

What the benchmarks actually measure

The project's fs-bench report compares twelve filesystem scenarios against a pinned Cloudflare Computer build. LayerFS reports a total of 5.20 seconds versus 8.88 seconds, with lower times in ten scenarios.

These are project-run measurements, with one sample per side on an arm64 Mac using Docker Desktop. The report says the total is a sum of scenario timings, not an agent-turn duration. Setup, mounting, committing and unmounting are outside those timers.

The comparison also uses different runtime configurations. It does not establish that an entire coding task becomes 1.71 times faster. For teams whose agents spend most of their time waiting for model responses, even a large filesystem improvement could have a modest effect on total completion time.

The durability boundary is the deployment decision

LayerFS 1.0 only supports its Disposable Store profile. The release explicitly excludes crash and power-loss durability. Saved history during normal operation should not be confused with a guarantee that this history survives an infrastructure failure.

That puts the most sensible initial use case around reproducible experiments: multiple coding attempts, temporary test environments and workloads whose valuable outputs are preserved elsewhere. Before adopting it more widely, test recovery expectations, conflict handling and the cost of building and maintaining the runtime.

The interesting direction is making an agent's workspace cheap to create and easy to inspect. Whether that becomes useful production infrastructure depends on how clearly temporary execution and dependable storage are separated.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn infrastructure launches and engineering decisions into clear stories that developers can understand and share.

Book a 30-minute call.