Two developers writing as Matthew and Matt have open-sourced Swarmfile, a filesystem and toolchain aimed at teams running fleets of coding agents against a single branch. In a Show DEV post, the pair describe the release as dual-licensed under MIT and Apache-2.0 and say the first full open-source release includes the self-hosted swarmfile-server, a swarmfile:// git remote helper, standalone tools named migrate, mirror, seed and doctor, and a block/manifest format specification with conformance vectors. The authors frame the post as "the honest version" of the announcement, and the claims below are theirs rather than independently verified findings.
The stated origin of the project is operational rather than theoretical. The authors say their own parallel agent sessions outgrew git worktrees and began interfering with one another, so they moved the fix down to the filesystem layer. They also note that a recent write-up from Anthropic about Scion reached similar conclusions, which they describe as good to see. That reference is offered as agreement in spirit; the post does not present it as a shared implementation or as validation of Swarmfile's design.
What the authors are seeking feedback on is a read-before-write rule. As the post explains, before saving a byte range an agent must first read it. Should an agent try to save a range whose current version it has not read, an ESTALE error refuses the save, instead of silently overwriting whatever another agent may have written meanwhile. Seeing that error, the agent is supposed to re-read the range and make another attempt. In the authors' account, a silent lost update thereby becomes a visible failure that can be retried.
That is a meaningful distinction for anyone who has watched two automated processes race on the same file. A silent overwrite can survive a whole session before anyone notices, whereas a refused write surfaces at the moment of conflict. The tradeoff is equally clear from the description: agents must be able to handle errors and retry, and any tooling that assumes writes always succeed will need adjustment. The post does not describe how retries are bounded, how contention is measured, or what happens when many agents target the same range repeatedly.
Considerable detail about the storage design is provided. A normal drive is how Swarmfile presents itself, and only the byte ranges a client opens are pulled, according to the authors, so that a repository bigger than the local disk can be mounted and opened quickly while consuming little local storage. FastCDC handles chunking and BLAKE3 handles hashing, with the blocks described as content-addressed, and they are said to travel over an iroh/QUIC peer-to-peer swarm. Local network first, then the wider swarm, then object storage is the stated retrieval order; the example given is that an entire office can be served by a warm cache on a NAS or on a colleague's machine.
Durability is addressed with Reed-Solomon 10+4 erasure coding, which the authors say means losing a machine does not mean losing data. Blocks can be kept on local disk or in any S3-compatible bucket, with S3, R2 and MinIO named as examples. The post also says the system can be self-hosted locally or on your own hardware, or used through the authors' hosted service, and that git, git-lfs or a desktop mount can be pointed at it.
Git compatibility is partial by design. The authors say git clone and fast-forward git push work through the remote helper, and that stock git-lfs can talk to the service directly, so a team could leave code on GitHub and point LFS storage at Swarmfile. When git is not wanted, the post lists native changesets, branches, locks and hosted CI as alternatives. Anonymous cloning is offered as a demonstration: the post gives the command git clone swarmfile://swarmfile/swarmfile-lfs and states that no account is needed.
The authors are unusually explicit about what does not work yet, and they point readers to a known-limitations page rather than burying the gaps. Pushes are fast-forward only, with no force push. Annotated tags are not supported. Git access is switched off for end-to-end-encrypted projects. The post describes the project as early and says the team keeps its gaps on one page. These are the authors' own statements about their software, not results of an independent audit.
Platform coverage is stated as Mac, Windows and Linux, with a self-serve free tier and no credit card required. The post includes a signup link carrying campaign parameters, which is worth noting when weighing how much of the write-up is product positioning versus technical report. No pricing beyond the free tier is given, and no benchmarks, latency figures or concurrency limits are provided.
For working developers and small studios, the practical question is whether a filesystem-level guard is a better fit than the coordination tools already in use. Git worktrees, branch-per-agent workflows and file locks each solve part of the problem, and the authors say worktrees specifically stopped being sufficient for them. A read-before-write refusal is a different kind of control: it does not prevent two agents from wanting the same range, it prevents the second one from succeeding without noticing. Teams already running agents in CI across multiple machines are the audience the post addresses most directly.
The peer-to-peer and erasure-coding layers also imply an operational shape that differs from a plain object store. Retrieval prefers nearby peers before the wider swarm and object storage, which could reduce egress and speed up repeated reads in an office or CI fleet, but it also means behaviour depends on cache warmth and peer availability. The post does not quantify any of that, so the benefit remains a design claim rather than a measured outcome.
Several questions remain open from the evidence supplied. There is no information about how the ESTALE rule interacts with tools that do not expect write failures, how conflicts are surfaced to a human, or what the hosted service costs beyond a free tier. The conformance vectors and format spec are described as published, but the post does not report third-party review of them. The comparison to Anthropic's Scion write-up is the authors' own observation and is not corroborated within the supplied material.
Reading this announcement as an invitation to stress-test a concurrency model, rather than as a claim about a finished product, is the most useful approach. Where their model holds up or falls over is something the authors explicitly ask, and those they want to hear from are named: people who have shared a build cache off a mounted drive or have run agent fleets. Such framing fits an early-stage release that has published its limitations alongside its features.
For freelancers and small teams, the low-commitment path is the one the post itself offers: clone the repository anonymously, read the format spec and known-limitations page, and decide whether the read-before-write semantics match how your agents and build tools already handle failure. If your tooling treats a failed write as fatal rather than retryable, the model will need adaptation before it helps. If your agents already retry on conflict, the filesystem may remove a class of silent data loss that is otherwise hard to detect.
What the evidence does not support is any claim that this approach is faster, safer in production, or widely adopted. The release is described as early, the licence terms are stated, the limitations are listed by the authors themselves, and no independent testing is reported. Treat the concurrency guarantee as a documented design property of an open-source project, and evaluate it against your own workloads before relying on it.