LayerFS 1.0.0 shipped on October 21, and the pitch fits in one sentence: every AI agent gets a complete, writable filesystem, and every change it makes becomes a checkpoint you can branch, rewind or merge.

That sentence describes a problem most people running agents already know. Two agents editing the same project overwrite each other. An agent that breaks something leaves no clean way back. Copying a repository for each worker solves it and wastes gigabytes.

LayerFS is an attempt to fix that at the filesystem layer instead of inside an orchestration framework. The project lives on GitHub under Ephemeral-AI-Lab and carries an MIT license.

What LayerFS 1.0 Actually Ships

The release is version 1.0.0, the first official one after a run of 0.1.x developer previews, and it ships as source rather than a hosted service.

Under the hood it is a FUSE filesystem written in Rust, backed by a single SQLite file. That file holds every branch, every commit and every content object. There is no database server, no daemon cluster, and no cloud account requirement. Each process opens the store directly.

The core vocabulary is worth learning, because the documentation leans on it:

A Branch is a writable line of commits
A Commit is an immutable snapshot of what changed
A Workspace is a mount that binds the whole committed tree without copying it
A Layer is what publishing a branch adds to main

If that sounds like container image layers crossed with Git, that is the correct intuition. The project's own documentation says as much and lists overlayfs, Btrfs snapshots, Git worktrees and the try utility as prior art.

How the Agent Filesystem Forks Without Copying

The mechanism is content-addressed storage plus a writable overlay, and the combination is what makes the promise hold.

When an agent mounts a workspace, it sees the entire committed tree, including dependencies, build output and ignored files. Nothing gets copied. Writes land in that workspace's own overlay until the agent commits, and unmounting deletes the overlay without touching history. That is why a new mount needs no reinstall step.

Content is chunked and hashed, so two files that share most of their bytes cost roughly one file's worth of storage. The project's own benchmark makes the scale concrete: a real project history with 157 snapshots and 4.94 GB of trees came out at 100.1 MB, about 19.9 times smaller than Btrfs with zstd compression. All 156 readable commits read back correctly.

Conflicts are handled by refusal rather than merging. Two commits that change the same file get rejected with a conflict error, unless a .lww rule marks those paths as last-write-wins. That is a blunt rule, and it is the right default for agent work, where a silent merge is usually worse than a failed one.

Why an AI Agent Checkpoint Beats a Git Commit

The distinction sounds academic until you watch an agent work. Git commits when a human asks. An AI agent checkpoint commits when a tool call ends.

LayerFS commits per tool call. A file write becomes a commit, and a Bash command commits when it finishes. A call that changes nothing commits nothing, which keeps the history readable instead of drowning it in no-ops. The result is a per-step timeline you can rewind to, not a per-task one.

That granularity changes what debugging looks like. Instead of rerunning a forty-minute agent session to see where it went wrong, you mount the commit before the bad step and inspect the tree. You can also branch from any commit at any depth, which makes it possible to run several approaches from the same starting point and keep whichever finishes.

An Open Source Agent Workspace in Practice

There are two ways to use it today, and only one of them is polished.

The polished path is the DSH plugin. LayerFS × DSH is a plugin for DeepSeek Harness, and it turns the filesystem into a visible workflow: agents fork branches, test them in sandboxes, merge and publish, and the Work and History tabs show every agent's branch live as it moves. If you already run DeepSeek Harness, this is the shortest route to trying the thing.

The second path is the SDK. There is a JavaScript SDK, and the benchmarks were run through it, which means the interface is real rather than aspirational. You install the daemon once as a single binary, then point it at a store file.

For an open source agent workspace, the MIT license matters more than usual here. Agent infrastructure is still consolidating, and a permissive license means the store format can be adopted by other tools without a commercial negotiation.

Where LayerFS Is Fast and Where It Slows Down

The benchmarks are unusually honest, including the rows where the project loses. All figures come from one run on an arm64 Mac with Docker Desktop and 8 CPUs, so treat them as a shape rather than a guarantee.

Where it wins:

Filesystem benchmarks: 5.20 seconds against 8.88 for the comparison, faster in 10 of 12 scenarios
Small files: faster in 9 of 9 operations on 100,000 files of 4 KiB
POSIX conformance: 8,798 assertions with zero unexpected failures
Stress: 3,755 of 3,755 entries identical after a commit and remount, with 5.21 GB captured in 4.9 seconds

Where it loses:

Sequential write throughput runs at about 0.31 times the comparison
Random write sits near 0.40 times
Sequential read lands around 0.81 times

The pattern makes sense. Content-addressed chunking rewards lots of small files and repeated snapshots, and punishes long streaming writes where hashing and chunking add overhead with no deduplication payoff. If your agent writes a single 20 GB video file, this is the wrong tool. If it edits source trees, it is aimed directly at your problem.

What LayerFS 1.0 Does Not Do Yet

The README states the biggest limitation before anyone else can: the store runs in a disposable profile only, with no crash or power-loss durability guarantee. In plain terms, do not treat it as the only copy of anything you cannot rebuild.

The project also lists what it deliberately skips. FIFOs, sockets, device nodes, set-id bits and separate atime and ctime tracking are not supported, which is why the POSIX conformance run keeps 76 percent of overlayfs's passes rather than all of them. Build systems that depend on setuid binaries will not work inside a workspace.

Two smaller gaps round out the list. There is no browser-based interface for inspecting history without the DSH plugin, and the Windows path runs through WSL2 and a Linux container rather than natively. For an agent filesystem at version 1.0, that set of omissions is reasonable. None of them are quiet surprises, which is the part that earns trust.

A safety note worth keeping in mind: because the store has no durability guarantee, keep the same backup discipline you would use for any working directory. Snapshots protect you from an agent's mistakes. They do not protect you from a disk failure.

Should You Try LayerFS 1.0?

LayerFS 1.0 solves a real coordination problem with a design borrowed from filesystems rather than from orchestration. Fork without copying, commit per tool call, branch from any point, and accept slower sequential writes in exchange for storage that stays small across hundreds of snapshots. If you run agents in parallel and have ever lost work to two of them editing the same file, this is worth an afternoon. If you need durable storage or full POSIX behavior, come back in a version or two.

For quickly validating agent collaboration, ChatGPT's mature ecosystem and easy integration make it worth a try.