git-ai Explained: Open-Source Scion for AI Coding Agents

git-ai is an open-source server that copies the design of Scion, the in-house source control system Anthropic built after git couldn't keep up with how many changes its coding agents were merging. It was written by a developer going by feder-cr, it's MIT-licensed, and it crossed 1,000 GitHub stars in its first day online. It is not Scion. Anthropic's version stays locked inside the company. This is someone else's homework, done in the open, and it's good enough that it's worth understanding even if you never run it.

Why did Anthropic even need a new version control system?

Anthropic's own engineering post, published October 13, 2026, lays out the numbers plainly: in May 2026 the company was merging around 2,500 code changes a day into its main repo. By September that number had passed 30,000 a day, roughly a 12x jump in four months. Most of that volume came from Claude agents writing and landing code around the clock instead of humans pushing a few times a day.

Git wasn't built for that pattern. Anthropic's main branch history had grown to almost 100 GB, and a compressed working copy was already over 25 GB. Clients that clone the whole history, merge queues that serialize pushes, and local history walks all assume a human sits down, works for a while, then pushes once. Agents don't work that way. They run thousands of short, narrow tasks that all want to land within seconds, often on the same shared branch.

So a team of seven people inside Anthropic spent five months moving the company fully off git. They built Scion for source control, a separate tool called Antique for code review, plus code search and access control to go with it.

What is Scion, actually?

Scion flips who does the work. In git, your laptop holds a full copy of history and does most of the heavy lifting; the server is mostly a dumb relay. Scion makes the server the one that commits, merges, rebases, and answers history questions, while clients keep a bounded local cache and fetch only what they need.

A few specific choices stand out:

• Changesets instead of snapshots. Each change records only what's different from its first parent, rather than a full tree pointer like a git commit.
• No packfiles. Scion drops git's compressed bundle files entirely, which also removes a chunk of repo maintenance work.
• Derived data, computed separately. Blame, path history, and skip lists aren't baked into the core log, they're built on top of it and cached.
• Three-tier caching. A daemon-cache-server chain reportedly hits a 99% cache hit rate, which is most of how Scion avoids hammering the backing store.

The payoff, per Anthropic's own numbers: a 200x smaller infrastructure footprint than the git mirror fleet it replaced, CI and research checkouts "two orders of magnitude faster" (seconds instead of minutes), a 25% CPU capacity win in CI, and an early internal rewrite of the git-to-Scion ingestion pipeline that used 20x less memory and ran 4x faster. Those are self-reported, from one company's monorepo, so treat them as a ceiling rather than a guarantee.

Anthropic is upfront that none of this is meant for you. The post says directly that Scion "is by no means a suitable replacement for git for general use," partly because it needs its own code review and code search tooling bolted on to be usable at all. It's internal, and there's no indication that's changing.

So what exactly is git-ai?

git-ai, which calls itself "gitai" in its own docs, is an independent rebuild of the ideas in Anthropic's post, not a copy of Anthropic's code, since nobody outside Anthropic has seen that. The repo says this explicitly: "gitai is an independent implementation of the publicly described design. It is not affiliated with or endorsed by Anthropic." Worth repeating, because a lot of the social posts around it blur that line.

Under the hood it looks a lot like a fork-in-spirit of Gitaly, GitLab's internal git RPC service, repurposed around Scion's server-centric model:

• ObjectService fetches individual objects and sparse trees instead of full clones.
• UserLand handles landing changes through rebase plus compare-and-swap, so you don't need a merge queue.
• A storage core on SQLite or PostgreSQL holds the changeset log and refs, backed by content-addressed object storage (local disk, S3, GCS, or Azure).
• An optional graft-cache daemon adds the multi-tier caching Scion describes.
• The CLI, called graft, talks to the server over gRPC, and there's a Go SDK if you want to build on it directly.

How does it stop agents from stepping on each other?

This is the part that actually matters day to day. When agents push to the same branch at once, classic git either serializes them through a merge queue or makes each one rebase-and-retry until it wins the race. At real concurrency, that retry loop gets expensive fast.

git-ai batches concurrent lands to the same branch into a single reference update using compare-and-swap, so a pile of compatible changes lands in one shot instead of fighting for a lock one at a time. When changes genuinely conflict, it hands them to a configurable resolver, an LLM provider or a deterministic rule set, through what the docs call a "versioned, vendor-neutral protocol." A model's proposed fix only lands if a verify.command check passes against the exact resulting tree. Deterministic rules can skip that gate and land directly.

There's a separate piece worth calling out: graft-verify. It watches the branch, materializes each new revision, and runs your test suite against it, only advancing a refs/graft/green/<branch> pointer when it's clean. If something breaks, it can bisect and auto-revert the culprit. That decouples "did it land" from "did it actually work," which is the thing merge queues often get wrong.

Does the benchmark actually prove it's faster than GitHub?

No, and the project is honest about that if you read past the headline number. The published benchmark runs 50 simulated agents landing 250 changes onto one branch, 20% of them deliberately conflicting, and compares git-ai's batching turned on versus off on the same server.

Those numbers look dramatic, and the gap between "1 attempt" and "27 attempts" per change is real and meaningful for anyone running agent fleets. But a closer read, including the one from Wavect's writeup, points out the test never touches an actual GitHub or GitLab server, explicitly excludes GitLab's integrated mode, and pins each batching channel to a single process, so it doesn't show how this scales across multiple channels either. Read it as "batching beats no batching in this specific harness," not "this beats GitHub."

How do you actually set it up?

If you want to kick the tires locally, the quickstart is short:

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

You'll need Go 1.26, a C toolchain, Meson, and Ninja on your machine, this isn't a go install one-liner. For anything beyond a demo, you adapt examples/graft/config.toml, point it at SQLite or PostgreSQL plus whichever object storage backend you're using, and run _build/bin/gitaly serve config.toml. Conflict resolution rules live in a separate resolve.toml, and the verify.command/verify.enabled settings control whether the test-gate actually blocks a landing.

None of this plugs into GitHub.com or GitLab.com as a drop-in. You're standing up your own server, your own storage, and your own agent auth tokens. That's a real commitment, not a config flag.

When do you actually need this?

Honestly, almost nobody reading this needs it today. If your team runs a handful of PRs a day, even with a couple of coding agents in the mix, git and a normal merge queue are fine. The friction git-ai removes only shows up once you've got a real fleet: think dozens of agents writing to the same branch concurrently, and your current setup is burning real time on retry storms and merge-queue backpressure.

It's also version 0.4.0. The maintainers say interfaces may still change before 1.0, and the repo itself lists known gaps like incomplete garbage collection of object packs. That's not a knock, it's an honest status label, but it means you're adopting infrastructure, not a library, at a point where the ground can still shift under you.

If you're already running an agent-heavy pipeline and you've measured actual merge contention as your bottleneck, this is worth a real pilot. If you're just curious because Anthropic's post was interesting, read the post, maybe spin up the quickstart once, and leave production alone for now.

Is it production ready?

Not in the way that word usually gets used. The project has unit, end-to-end, multi-node, crash, and fuzz tests, which is more rigor than most week-old GitHub repos ever get, and that's a point in its favor. But pre-1.0 interfaces, an unfinished pack-GC story, and a benchmark that hasn't been run against a real GitHub-scale workload all mean you should treat it as serious infrastructure in testing, not a swap-in replacement for your current git host.

For more on how coding agents are reshaping the tools around them, see our pieces on how Claude Code, Codex, and Cursor compare as agent platforms, what shipped with Claude Opus 5, and our running list of the top AI tools worth watching in 2026.

Watch