git-ai (gitai): An Open-Source Take on Anthropic's Scion for Coding Agents

A developer called feder-cr has published git-ai (the project calls itself gitai), an open-source server that tries to recreate the source-control design Anthropic described for Scion. The repository, feder-cr/git-ai, was created on October 15, 2026 and had gained about 1,890 stars by October 18. It is MIT licensed, at version 0.2.0, and explicitly not affiliated with Anthropic.

If you followed our coverage of Anthropic replacing Git with Scion, this is the obvious next question: can the rest of us run something like it? The honest answer is "partly, and early". This post covers what the project does, how to try it, the numbers it reports, and what remains unproven.

TL;DR: questions people are asking

What problem is it solving?

Classic Git hosting assumes a human who clones a repository, works for hours, then pushes once. Coding agents behave differently. The git-ai README describes "thousands of short-lived tasks, each touching a few files, each wanting to land in seconds, all on the same branches." Full clones, merge queues and client-side history walks become the bottleneck.

Anthropic's engineering post gives the scale that motivated Scion: merges grew from about 2,500 code changes a day in May 2026 to more than 30,000 a day by September, and source control became the main bottleneck. Anthropic says it migrated its monorepo off Git in five months with a seven-person team, and reports its infrastructure using roughly 200 times less CPU and memory than the old mirroring setup. Those are Anthropic's figures about its own system; they say nothing about git-ai.

Anthropic is also clear that Scion is not a general Git replacement. It makes sense for enormous monorepos and is tied to Anthropic's internal tooling. The stated goal of publishing was to share ideas so that Git platforms could adopt parts of the model, such as server-side RPCs and tree-and-blob negotiation. git-ai is one community answer to that invitation. For the side-by-side differences see our Scion vs Git comparison.

How does git-ai map to the Scion ideas?

The README contains a table pairing each Scion idea with a gitai feature. The ones that matter most to a builder:

Underneath, repositories remain normal Git repositories, and every upstream Gitaly RPC keeps working. That is a meaningful design choice: it means existing Git data can be imported rather than converted, and the README suggests starting in "shadow mode", importing repositories, then switching to authoritative mode.

Why a compare-and-swap instead of a merge queue?

Two ribbons being untangled, illustrating how git-ai lands concurrent agent changes without a merge queue

A merge queue serializes changes. With a few dozen human developers that is fine. With hundreds of agents it means long waits or constant retries. In a compare-and-swap model each lander says "update this branch from tip A to tip B, only if the tip is still A." If it fails, the lander rebases and tries again. The innovation the README claims is batching: concurrent lands on one branch are folded into one reference update, so a burst of 50 agents does not mean 50 separate retry loops.

Anthropic makes a related point in its own post: traditional merge queues with global locks do not suit agent-scale development, so it leans on post-merge and pre-deploy testing instead. That is the idea behind gitai's graft-verify.

What does the benchmark actually show?

The README reports one scenario: 50 agents each land 5 changes on a single branch, and 20 percent of the changes conflict on purpose. "Classic" is the same server with batching turned off, so each agent rebases and retries its own compare-and-swap up to 20 times. It was measured with an acceptance script on one 16-core machine, over two runs.

The 50 changes gitai does not land are the deliberately conflicting ones, because that run used no conflict resolver. With the deterministic resolver in the repo's resolve.toml, the README says every conflict is resolved and all 250 land.

Read this with care. It compares gitai against a handicapped version of itself, not against GitHub, GitLab or Gerrit. It runs on one machine, with a synthetic conflict pattern the author chose. It is a useful demonstration that batching beats naive retry under contention; it is not evidence that gitai outperforms existing platforms. We could not find an independent reproduction.

How do I try it?

From the README, you need Linux or macOS, Go 1.26, a C toolchain, Meson and Ninja, because the build compiles a bundled Git.

git clone https://github.com/feder-cr/git-ai.git
cd git-ai
make build
examples/graft/quickstart.sh
./_build/bin/graft

The quickstart brings up a server, a cache daemon, two agents and a land in a temporary directory, so it is safe to experiment with. To run a real server, the README says to adapt examples/graft/config.toml and start it with _build/bin/gitaly serve config.toml. Adding a [graft.storage] section moves repository state into a database and object storage.

A reasonable first experiment for a team that runs several coding agents: point two agents at the quickstart server and have both edit the same file, then watch the changeset log and see how the resolver handles the clash. Do not point it at a repository you cannot afford to lose; the maintainer lists known gaps, such as garbage collection of packs in the storage core, in LIMITATIONS.md.

Where does this fit with other agent Git tooling?

Several projects are rethinking Git for agents from different angles:

• Cloudflare Artifacts offers a hosted Git remote for agents.
• Cursor's Origin is a Git hosting alternative aimed at agent workloads.
• Our Scion vs Git vs Cursor Origin comparison lines up the hosted approaches.
• The server-centric vs distributed version control decision guide helps decide whether you need any of this.

What sets gitai apart is that it is self-hosted and open, and that it copies a specific published architecture instead of inventing a new one. What it lacks is a track record. Hosted services come with operations and support; gitai comes with a README and a version number below 1.0.

Branching commit history dots, illustrating the changeset log that records every reference update in git-ai

What are the risks and open questions?

Provenance and credit. gitai is an independent implementation built from a public description, and it says so. Scion's own write-up was the subject of a dispute over credit to Meta's Mononoke and Sapling work; we covered it in our attribution dispute explainer. A derivative of Scion inherits that history of prior art.

Maturity. Version 0.2.0 with 37 commits is young. The README says everything described is covered by unit, end-to-end, multi-node, crash and fuzz tests, but that is the author's statement, and interfaces may still change.

Fork maintenance. It started as a fork of GitLab's Gitaly. Following upstream security fixes in a fork is an ongoing cost, and a solo or small-community project may fall behind.

Agent permissions. The design gives agents first-class identities with tokens and allowlists. That is the right shape, but permissions only matter if they are configured. If you let autonomous agents land code, review what they are allowed to do before they do it. For detecting or blocking dangerous agent actions, AgentBeam is the agent security platform from the explainx.ai team.

Hype versus use. Star counts after three days measure curiosity, not production adoption. We found no Hacker News thread for the project at the time of writing, so there is no community hands-on report yet to quote.

Should you use it?

If you run a handful of agents on ordinary repositories, no: Git plus a normal merge queue is fine, and you gain nothing from operating a database-backed Git server. If you are experimenting with swarms of agents landing changes concurrently, or you want to study how a Scion-style system behaves without access to Anthropic's, gitai is a useful, readable reference implementation, and the design documents in doc/graft/ explain the reasoning behind each phase.

Watch for three things: an independent benchmark against a mainstream Git host, a 1.0 interface freeze, and whether the maintainer builds a community that keeps up with upstream Gitaly. We will add an update here if any of those land.

Related reading

• Anthropic Replaced Git With Scion
• Scion vs Git: side by side
• Scion vs Git vs Cursor Origin
• Server-centric vs distributed version control for AI agents
• Scion and Mononoke: the attribution dispute
• Cloudflare Artifacts: a Git remote for agents
• Official: Anthropic, Redesigning source control and the git-ai repository

Details reflect the repository README and Anthropic's post as of October 18, 2026; star counts and version numbers change quickly.