Swarms of agents. One project. No overwritten files.
Run a coding agent per task instead of a clone per task. Mount the project once per agent - no clone, one shared cache - and let the engine refuse a stale save rather than bury a teammate’s. Full Git interop, an open-source server you can self-host, and nothing to reconcile by hand.
More agents, more copies, more collisions.
One clone per agent doesn't scale.
A worktree or a full clone per agent means a copy of the repo, a dependency install, and a disk bill for every session you run - and on a repository with large assets, a clone an agent has to wait for before it can start.
Two agents, one file, last writer wins.
Agents write whole files back after reading them. When two edit the same file - or the same branch - the second write silently buries the first. You find out in review, or in production, not at the write.
Scattered working copies drift.
A dozen agents on a dozen clones means a dozen versions of the repository with no shared history, no shared cache, and no single place a human can review what actually changed.
Swarmfile gives every agent a workspace without a copy - and makes a collision visible instead of silent.
Built for many agents, not a single checkout.
A mounted workspace per agent.
Mount the project once per agent over the same shared blocks - no clone, no second copy on disk, and one dependency cache per machine instead of one per session. An agent opens the files it needs and streams only those bytes; a per-agent branch is there when you do want one isolated. The coding-agents guide has the setup.
No lost updates, no overwrites.
A save carries the version its writer read. If another writer - human or agent - moved the file first it is never applied over them: in hard conflict mode (recommended for agent writers) the save is refused (ESTALE) and handed back to re-read and re-apply, and in the default mode the file parks read-only with the conflict surfaced. Unmatched paths keep that refusal; only paths a project opts into with.swarmfile/conflict-policy use newest-wins, through the hub's recorded conflict row.
Online across machines, and offline on one.
Agents on one machine share the mount and finish work offline; across machines they broadcast changes over the swarm, so a teammate on the other side of the world sees a file move within seconds - from a peer when one is closer than the cloud, never a full re-clone.
Still Git, still yours.
The same project serves git clone, git push and Git-LFS, so an agent that only speaks Git works too, and a human reviews the same branches. Keep your host and stream the big files, or let the project be the remote - no second system to reconcile. Git & Swarmfile.
Open source, and yours to self-host.
The server, the standalone tools and the libraries are open source, and the CLI and Desktop clients are free. Run the whole thing against a server you host, in your region, on your own bucket - useful when the team is large and the data can’t leave the building. How self-hosting works.
CI that triggers on the change.
When a change lands, component systems - including self-hosted runners - get a near-real-time notification, so a job watches the part of the project it cares about and reacts, re-running and shipping without materialising the rest of the monorepo. Hosted CI guide.
Prefer to start from the terminal? The developer quickstart has the real commands for mounts, Git-LFS and CI.
How long a workspace actually takes.
Engine start to the first read of a real file (up to 64 KiB; this file is 6.1 KiB (6,239 B)) in the production swarmfile-lfs project - no clone, no copy, no install.
| What | Cold (fresh cache) | Warm (same machine) |
|---|---|---|
| Engine start → mount attached | 1.6 s | 1.1 s |
| Engine start → first byte | 2.5 s | 1.2 s |
| Read (6.1 KiB), already attached | - | 3 ms |
Median of three runs on 2026-10-21, Swarmfile 0.3.12, macOS 26.5.1 on an M4 Max MacBook Pro, against a 24 MiB project over the public internet. The read includes one process spawn, so it is a ceiling on a native app’s own read. Reproduce it with scripts/scale/mount-bench.sh --file README.md --warm; the full method and per-run numbers are in the repository.
Start building with a swarm. Lose the copies.
Trial Swarmfile on one project and run your agents against the mount. 7-day Pro trial. Card on file, nothing charged until day 7. A trial covers up to 2 seats; add more once it converts. Or self-host the open-source server and point your agents at it.
Cancel anytime before day 7.