How GitSwarm works
GitSwarm has three parts: a shared Git repository that acts as the swarm's memory, a pool of identical workers that each choose their own next move, and a light execution harness that schedules workers, isolates them, and validates what they publish. There is no planner, no assigned roles and no privileged final judge.
The repository is the memory
Each task starts as a repository containing the task specification. Every piece of work a worker publishes becomes one atomic, immutable commit: a draft solution, a test, an experiment and its result, a repair, or a negative finding. Branches let competing approaches grow side by side, so the swarm never has to commit to one direction too early.
Each commit records two kinds of history. Its Git parent is the state the worker started from. Its informed_by= field lists the other commits the worker relied on, including commits on other branches. We call this second link semantic inheritance: it lets a worker build on one branch while borrowing a discovery from another, without merging. Following both links backwards from any commit gives its ancestry: all the earlier work it builds on.
Identical workers, no manager
Every worker runs the same model with the same instructions. Nobody is told to be a solver, a verifier or an integrator. Each worker looks at the repository and decides what would add the most value right now. Specialization, when it appears, comes from the state of the repository: early workers write first drafts because nothing exists yet, and later ones repair, test, combine and compare. We return to this below.
Asynchronous execution
The harness keeps up to C workers running at once (five in our benchmark runs) and launches a replacement whenever a slot frees up, until a budget of B worker episodes is spent. Workers never wait for each other, so a commit is visible to every worker that starts after it is published.
Seeing the live swarm
Work that hasn't been committed yet is invisible in Git, so workers get two read-only views of the live run. Every worker receives a snapshot of the dashboard when it spawns, and can fetch an up-to-date one at any time by running gs_dashboard. It shows the remaining budget, how many workers are in flight, and the nomination tally, which is explicitly labelled as not being evidence of correctness; in research runs it shows shared GPU usage and the best validation score instead. To see what other workers are doing right now, a worker runs gs_inflight: it lists the workers in flight, and gs_inflight inspect shows one worker's public log of what it announced it would do, its progress updates, and its uncommitted changes. Each worker writes to this log itself, so others can avoid duplicating its work. Neither view assigns work.
Anatomy of one episode
A worker episode is one agent run from spawn to exit, inside its own isolated Git worktree. The prompt asks it to understand the existing work before acting, to scope one bounded contribution, and to say up front what would make it give up.
Three ways to end an episode
Every episode ends with exactly one of three actions. Validation checks only that a commit follows the task's publication rules (required files, allowed paths), not that it is correct.
Decentralized readout
Eventually the swarm has to decide which commit is its answer. Rather than handing this to a privileged judge, GitSwarm leaves it to the workers too. Nominations are stored outside the commit graph, so workers can evaluate candidates while others keep building new ones, without changing anyone's ancestry. When the budget runs out, the candidate with the most nominations is submitted, with ties broken deterministically. For the research tasks, which have a validation score, the best-scoring model is selected instead.