Swarm turns Git worktrees into a control plane for AI agents
A Rust desktop app that treats parallel coding agents as isolated workspaces with attachable sessions, not as more chat windows.
- Swarm's main idea is that parallel agents need isolated workspaces and attachable sessions, not just better prompts.
- The repo's split storage model keeps global tracking separate from per-repository state, which makes local agent work easier to manage and prune.
- The desktop layer matters because terminal fidelity is part of the workflow, not a cosmetic extra.
- Swarm competes by orchestrating development on one machine, not by reinventing the model layer.
Most AI coding tools start at the prompt. Swarm starts lower, at the machine. It assumes the hard part is not getting an agent to write code, but keeping several agents from stepping on each other while they do it.
The repository comes from penberg, and the code reads like a tool built by someone who has watched terminals and working directories turn into a mess. It is not trying to become a general platform. It is trying to make one very specific workflow boring.
The bet: isolate the work, not just the prompt
That is why Swarm is built around a simple hierarchy: repository, workspace, session. The repository is the tracked source of truth. A workspace is a physical directory backed by a Git worktree. A session is a persistent terminal process that can be attached later, from the CLI or the GUI.
The constraint isn’t compute anymore. It’s orchestration.
That sentence is the real design brief here. If orchestration is the bottleneck, the product should live where orchestration happens: the filesystem, the terminal, and the supervisor process.
How the system is laid out
The unusual part is the storage layout. Swarm keeps a global index.db for repository tracking, then writes a repo.db inside each repository folder for workspace and session metadata. That split makes state feel portable. Remove a repository folder and you remove most of its local metadata with it.
Sessions are not throwaway subprocesses. Swarm spawns a supervisor, keeps a Unix domain socket for attachment, and tracks state transitions from starting to running to exited or failed. That is the difference between ran a command and managed a living agent.
We realized that what the world needed wasn’t a better agent. It needed a framework for intelligence at scale.
Why worktrees matter more than clones
Swarm does not ask every agent to share one checkout. It materializes workspaces with Git worktrees, which means the shared history stays shared while each agent gets a separate working tree and a separate set of changes. That is a better fit for parallel coding than cloning the repo five times, and it wastes less disk and setup time.
| Dimension | Typical setup | Swarm |
|---|---|---|
| Isolation | Each agent gets a full clone, so disk and setup multiply. | Each agent gets a worktree from one repository, so isolation is lighter and faster. |
| State | Session state lives in a shell tab or an ad hoc script. | Session state is modeled explicitly and can be reattached. |
| Attachment | You reconnect manually or lose context. | A Unix socket reconnects the CLI or GUI to the same supervisor. |
| Legibility | Context is spread across terminals and notes. | A native dashboard keeps the swarm readable. |
That is the point of the architecture. Swarm does more than wrap git worktree and a terminal in a nicer shell. It makes those primitives the contract, which is exactly what an agent-heavy workflow needs.
The desktop layer is not decorative
Swarm's GUI is not a wrapper around the CLI. It is a GTK4 application with PangoCairo rendering and a vendored libghostty-vt terminal core. That choice matters because terminal fidelity is not cosmetic when you are attaching and reattaching to live agent sessions. The interface has to keep up with the machine.
The CLI and GUI are both first-class entry points, not separate products. swarmctl handles repository, workspace, and session commands. ui/swarm.rs surfaces the same objects in a desktop dashboard. The shared error model, built with thiserror, keeps Git, database, and terminal failures from turning the app into a pile of special cases.
That is what makes Swarm interesting even if you never adopt its exact stack. It sketches the missing layer between a model call and a development environment, a layer where isolation, attachment, and persistence are first-class.