Short answer: git-ai is not Scion, so do not treat it as Anthropic’s system, and do not replace Git with it this week.
Scion is the version-control system Anthropic built for its own giant repository and did not release. git-ai (also written gitai; inside the code the name is Graft) is a community server that copies the public ideas. Its own limits page says it is not a Scion implementation. Git, the tool already on your laptop, is still the right tool unless hundreds of always-online agents are landing on one branch faster than your host can take them one at a time.
Start with a folder, before any product name
A project on a computer is a folder of files. A file is a pile of bytes (the raw numbers that store the text, not the name you see in the folder). If you want yesterday’s version, the dumb method is to copy the whole folder and date the copy.
A version-control tool (a program that remembers each saved copy, so you can return to one) exists so you do not keep a full extra folder every time. Git (the usual one of those programs; Linus Torvalds wrote it in 2005 so Linux kernel developers could work apart and still share) is that diary for almost every public code project.
What Git actually stores
Git does not store the latest folder as one zip. It stores three kinds of records, and a sticky note that points at the newest one.
A blob (the stored bytes of one file, named by a fingerprint of those bytes, so identical files are stored once) is the first record. A tree (a list of names pointing at blobs, which is one snapshot of a folder) is the second. A commit (a saved snapshot plus who saved it, a message, and a pointer to the previous snapshot) is the third. A branch (a movable sticky note that names one commit, such as main) is not a copy of the files. It is a pointer.
Because each commit points at its parent, history is a chain. Walking that chain to answer who last changed this line is called blame (a history query, not an insult). Doing it needs the chain. That is why the next section gets expensive.
Why a full copy gets heavy
A clone (a full copy of that chain, plus a working copy) is what git clone makes. A working copy (the plain files you can open and edit) sits beside the hidden chain in a .git folder. Offline work is the point: the laptop can compute a difference, read blame, and check out an old snapshot with no server.
Anthropic (the company that makes Claude) wrote on 13 October 2026 that this design is right for the vast majority of repositories. Their own repository stopped fitting it. These figures are theirs, from that post:
| What | Their figure | What it is not |
|---|---|---|
| Merges per day, May 2026 | around 2,500 | Not a count of human programmers |
| Merges per day, September 2026 | over 30,000 | Not a promise that every company will hit this |
| History of the main branch alone | almost 100 GB | Not the size of a normal app repo |
| Compressed working copy | over 25 GB | Not the size of the history |
| CI checkouts per day | on the order of 25 million | Before developer machines, agent sandboxes, and research jobs |
| If every checkout fetched naively | over 600 PB of Git traffic a day | Their estimate of a bad method, not traffic they measured on the wire |
CI (continuous integration: a robot that checks out the code and runs tests whenever something changes) is most of that checkout count. A checkout (making the working files exist on disk for one snapshot) is cheap when the chain is small. At their size, copying the chain for every robot was the bottleneck (the slowest step that holds up everything behind it).
A merge queue (a line where changes are combined into the main branch one after another, so two people do not overwrite each other) is the other wait. It was built for humans who push a few times a day. It serializes (makes things happen one at a time) work that agents want to finish in seconds.
What changed is who the client is
Anthropic’s own correction, in their words: they were using Git as a centralized system with one authoritative copy, while nearly all of their clients were agents and jobs that are online by definition. The properties that make Git excellent for distributed, offline work were getting in the way.
A coding agent (a program that edits the project in a loop, reads files, and runs commands, rather than a chat box that only talks) does not sit on a train with no network. It lives next to the server. So the full offline copy, which is Git’s gift, becomes a tax.
They also say the concepts only make sense for truly enormous monorepos (one giant repository that holds many projects together), with either tens of thousands of engineers or swarms of agents writing code, and that Anthropic’s ability to spend tokens (the small chunks of text a model is billed on) for internal use far exceeds what other businesses would want to spend.
What Scion is, in their words
Scion is the in-house system they migrated that monorepo onto, in five months. A team of seven people built Scion and Antique (their code-review surface: the screen where a change is accepted or sent back) and half a dozen related systems. The client program is called scn. There is no public download. There is no license. There is no repository.
In Scion, the unit of work is a changeset (an entry in a write-ahead log, which is a diary written in order so a crash can replay it). A changeset stores most of what a Git commit stores. The difference they state: a Git commit points at a full tree, while a changeset stores the list of files that changed relative to its first parent, plus content-addressed pointers (pointers named by the bytes, so the same bytes live once) into blob storage.
Their design principles, all from that post:
- Clients are always online, and they fetch data when they need it, instead of holding a complete copy.
- The server creates commits, merges, rebases, and answers history. The client keeps a bounded cache and lays files on disk. It can compute very little on its own.
- The same questions are an API (a fixed way for a program to ask), so many jobs never need a local repository.
- Every component scales sideways. There is no fully materialized copy of the repo anywhere, even on the server. They say there is no equivalent of packfiles (Git’s compressed bundles of objects), so no repository maintenance of that kind.
- Creating a commit must cost in proportion to the change, not the whole repo, and must not take a global lock (a wait-I-am-using-this flag).
- The working copy is optional. A sparse checkout (only the directories you asked for) and a virtualized checkout (files appear on disk only when something reads them) are the normal path.
Three results they report, which are three different claims, not one:
- The Scion footprint is 200 times smaller than their previous Git mirroring setup, in CPU and memory. That is versus mirrors (extra full copies kept so checkouts could be spread out), not 200 times faster than GitHub.
- CI and research checkouts are two orders of magnitude faster, seconds rather than minutes.
- CI alone realized a 25 percent CPU capacity win.
On 15 October they updated the post to name the prior art. Huge-monorepo source control already existed, notably Google’s Piper and Meta’s Sapling. The server half of Sapling, Mononoke, pioneered many of the techniques, in particular the Bonsai data model (a way of storing a change as the files that changed, which is the family Scion’s changeset sits in). So agents did not force the invention of server-side history. That family is older than this news cycle.
The sentence the headlines skip
Anthropic wrote: Scion is by no means a suitable replacement for git for general use.
They continue: it diverges from Git, so a company would have to migrate every piece of the development lifecycle, and it needs its own code review, code search, and CI. Their versions of those are bespoke (built for them, not as a product). They say a public version that tried to please everyone would not be very useful. Their offered contribution is narrower: share the early view, and partner with GitHub, GitLab, and the open-source community.
If your repository is not a 100 GB monorepo with tens of millions of checkouts a day, you are in the group they said Git still fits.
What appeared two days later
git-ai is a public repository, feder-cr/git-ai, MIT licensed (a short license that lets you use, change, and sell the code, including in closed products, if you keep the notice). The README says Scion is internal, so the author built gitai as an open-source version of that design. The same README’s small print says it is an independent implementation of the publicly described design, not affiliated with or endorsed by Anthropic.
Inside the code the extensions are called Graft. The command you type is graft, not git and not scn. The server is started with _build/bin/gitaly serve config.toml. That binary name is the tell. The project started as a fork of Gitaly (GitLab’s server that runs Git operations over a remote call, so GitLab itself does not shell out for every button). Upstream Gitaly remote calls keep working. The non-MIT ee/ directory from upstream is not in this repository. Normal Git repositories still sit underneath.
Vendor neutral, in their sentence: the server never calls a language model (the text-prediction system you pay a lab for), and every AI feature works with any provider, or none. A conflict resolver (the program asked to combine two edits of the same lines) is something you plug in. It can be a model, a deterministic tool (the same input always gives the same output, with no model), or nothing.
The README’s version line: 0.2.0. Interfaces may still change before 1.0. Requirements they list: Linux or macOS, Go 1.26 (the compiler for the Go language), a C toolchain, plus Meson and Ninja because the build compiles a bundled Git. Windows is not in that requirement line.
What the README claims it implemented
The README maps each public Scion idea to a Graft piece. This is their map, not a test log:
| Public idea | What they say Graft does |
|---|---|
| Clients fetch only what they need | graft clone and graft sparse materialize only the paths you ask for |
| History runs on the server | Blame, path history, ancestry, and code search are memoized, meaning computed once and saved |
| Land without a merge queue | UserLand rebases onto the current tip and lands with a compare-and-swap |
| Conflicts | A resolver you choose, through a versioned protocol, or none |
| A log of who landed what | Every accepted reference update is an entry clients can list or watch |
| Scale the servers out | Changesets in SQLite or Postgres; packs in object storage; nodes are caches |
| Test after landing | graft-verify tests the tip, bisects a failure, and reverts the culprit |
| Agents as users | Per-agent tokens, an allowlist of calls, and branch policies |
A compare-and-swap (write the new pointer only if it still has the value you read; otherwise someone else landed first and you must retry) is the lock-free trick. A rebase (replay your change on top of the newest tip, as if you had started from there) is what they do before that write. Landing means the main branch pointer moves. There is nothing to push, because the write already happened on the server. That is the same shape as Scion’s there-is-nothing-to-push, implemented here on top of Git objects rather than as Scion’s storage.
Read the benchmark before the banner
The race in the project’s README banner is this test. Fifty agents each try to land 5 changes on one branch, so 250 changes. Twenty percent conflict on purpose. Classic is the same server with batching turned off: every agent rebases and retries its own compare-and-swap, up to 20 attempts. Two runs, on one 16-core machine, via examples/graft/demo/acceptance-phase4.sh.
| 50 agents, 250 changes | Classic, batching off | git-ai, batching on |
|---|---|---|
| Changes landed | 100 to 101 | 200 |
| Attempts per landed change | 27 | 1.0 |
| Lands per minute | 240 to 272 | 1,862 to 2,544 |
| p99 latency | 6.3 to 7.0 seconds | 1.5 to 1.8 seconds |
p99 (the slow end: 99 percent of waits were shorter than this) is a tail, not the average. The 50 changes git-ai does not land are the planned conflicts, because these runs use no resolver. The README says that with the deterministic resolver in examples/graft/demo/resolve.toml, every conflict is resolved and all 250 land.
The limits page adds the caveats the banner does not. The acceptance is two runs, one machine, one workload, seed 1, conflict rate 0.2. The runs vary a lot, the benchmark saturates the machine, and the stretch goal passed by only 3.7 percent in one of the two runs. An earlier phase, on the final tree of that phase, had p99 with batching on worse than batching off at 50 and 100 agents. Do not average those into a new number. The project’s own page says the pretty table is a narrow, noisy test.
What this does show, if you grant their method: on one busy branch, retrying a compare-and-swap from every agent is wasteful, and grouping those lands in one process cuts the retries. What it does not show: a speedup versus GitHub, versus GitLab, versus Sapling, or versus Anthropic’s Scion.
Why git-ai is not Scion, by its own limits page
The limits page (doc/graft/LIMITATIONS.md) is written for people deciding whether to run it, and it leads with this. These are the page’s own headings:
- Not a hosting product. No web UI, no issues, no merge-request review workflow, no CI.
- Not a replacement for GitLab. Standalone mode drops the GitLab dependency for access checks and hooks. It does not grow GitLab’s features.
- Not a Scion implementation. It adopts ideas from the article. Internal details of Scion are not public and are not reproduced.
- Not a security boundary by itself. The access policy is local configuration. Whoever can edit that file can change who may write where.
That third bullet is the whole post. The README’s phrase “an open-source version of that design” and the limits page’s phrase “not a Scion implementation” are both in the tree. Believe the limits page when you decide what you installed.
Other limits that change a rollout, still from that page:
graft cloneneeds the branch to exist. An empty repository cannot be cloned. The graft command and the SDK cannot create a repository.- graft does not speak the Git protocol for push and pull. Use the server’s normal Git protocol for that. Your existing scripts do not all move over by renaming the remote.
- Object durability assumes a local journaling filesystem, ext4 or xfs, not NFS (a disk mounted over the network).
- The end-to-end tests run on one machine. Multi-node behaviour is untested. Land batching is per Gitaly process and in memory. Two nodes do not share one lane. The README’s “you add nodes to scale” is the design goal. The limits page says the tests have not shown it.
- The changeset log is per node and is not replicated. After a failover (the standby taking over), clients must not reuse a cursor from the old primary.
- Agent tokens are read at startup. Rotating a token needs a restart. There is no management API for the policy. There are no users, groups, or per-repository roles.
- The shared token is an administrative credential. A holder can act as any user, as with upstream Gitaly. One hook path still trusts a payload from that shared token.
- CreateRepositoryFromSnapshot downloads a tar the client chooses and extracts it without filtering. The archive can carry hooks. Agents are not supposed to be able to call that remote method. A holder of the shared token can. Treat the shared token like a root password.
- The CLI cannot yet materialize a conflict in the workspace for an agent to fix by hand.
- Policy globs cannot say “allow this only if the change touches docs/”. A reference no rule matches is denied once the policy is non-empty, which also denies tags unless a catch-all allows them.
The README’s example of a known gap is garbage collection of packs in the storage core. The limits page talks about packs left behind by a lost compare-and-swap until housekeeping prunes them. Do not plan a multi-year monorepo on an unfinished pack cleaner.
So should you switch?
| Your situation | Do this |
|---|---|
| One person, one repo, a laptop that must work offline | Stay on Git. Anthropic said that design is the right one here. |
| A few agents on GitHub or GitLab, stepping on each other | Give each agent its own worktree, a second folder of the same repository checked out on another branch, before you stand up a new server. |
| CI is slow because every job downloads the whole history | Try a partial clone, which delays blobs until something needs them, and a sparse checkout, on the Git you already have. |
| Hundreds of agents landing on one branch, and the merge queue is the wait, and you can operate a server | The quickstart below is a fair experiment, in a temporary directory. It is not a migration plan. |
| You wanted Anthropic’s Scion, Antique, and their 200x footprint | You cannot have them. Those numbers are about their monorepo and their mirrors. git-ai does not include them. |
A worktree is the ordinary Git answer to two workers in one repo, and it does not require Go 1.26 or a Gitaly process. A partial clone is the ordinary Git answer to stop downloading every blob. Use those until you can point at a queue that is actually the bottleneck.
How to look, without migrating
Their quickstart, as the README gives it:
git clone https://github.com/feder-cr/git-ai.git cd git-ai make build examples/graft/quickstart.sh ./_build/bin/graft
examples/graft/quickstart.sh is supposed to start a server, a cache daemon, two agents, and a land, in a temporary directory. That is the right first run. A daemon (a helper that stays running in the background) is the cache process. A land, again, is the server moving the branch pointer.
To point it at a real repository they say: adapt examples/graft/config.toml, start _build/bin/gitaly serve config.toml, and only then consider a [graft.storage] section. Start in shadow mode, import, then switch to authoritative. Authoritative means this server, not your old host, is the one allowed to decide the branch pointer. Do not flip that on a repository you cannot restore.
There is no production config here, on purpose. The limits page says the policy file is the security boundary, tokens are loaded only at startup, and the shared token is administrative. If you cannot explain those three sentences to the person who would get paged, you are not ready to run it.
What I would not believe
- Anthropic open-sourced Scion. The 13 October post says the opposite, and asks to partner with GitHub and GitLab instead.
- git-ai is Scion. The limits page says it is not, because Scion’s internals were not published.
- Ten times faster than Git. The table compares batching on versus batching off, on their server, on one machine, on one workload.
- The server calls Claude to merge. The README says the server never calls a language model. A resolver can, if you configure one. With no resolver, planned conflicts do not land. That is the 200-versus-250 gap.
- A star count. Posts on X this week have said the repo climbed past a couple of thousand stars in a few days. Stars are clicks on a bookmark. They are not checkouts, and they are not a code review.
- It scales out because the diagram has many nodes. Multi-node behaviour is listed as untested. Batching does not coordinate across processes.
Where this sits next to the tools you already run
If the pain is two agents editing one folder inside an IDE, that is a worktree problem. The JetBrains Air note on this site walks through why a branch is a pointer and a worktree is a second folder: JetBrains Air is not a new model.
If the pain is an agent with a shell on the machine that holds your keys, a faster branch pointer does not fix that. Isolation is a different wall: coop Claude Code sandbox.
If the pain is which agent should land the change, git-ai will not choose. It will record the actor of the token that landed, once you are already running it.
Common questions about git-ai and Scion
Is git-ai the same as Anthropic’s Scion?
No. git-ai’s LIMITATIONS.md says it is not a Scion implementation: it adopts ideas from Anthropic’s 13 October 2026 post, and Scion’s internal details are not public. The README also says it is not affiliated with or endorsed by Anthropic.
Can I download Scion?
No. Scion is internal to Anthropic. There is no public download, no license, and no repository, and Anthropic wrote that Scion is by no means a suitable replacement for git for general use.
Is git-ai faster than Git or GitHub?
Its benchmark does not say that. The README compares the same server with batching on versus batching off: 50 agents, 250 changes, two runs on one 16-core machine. It is not a comparison with GitHub, GitLab, Sapling, or Scion.
What should I try before running git-ai?
Give each agent its own Git worktree, and use a partial clone with a sparse checkout if CI downloads the whole history. Both work on the Git you already have. Try the git-ai quickstart in a temporary directory only if a merge queue on one busy branch is your real wait.