Is Scion open source? Can I use it?
No. Anthropic's post does not announce an open-source release, says Scion is not suitable for general use, and calls its internal components highly bespoke. Some secondary coverage headlines it as open source, which does not match the original.
If you want to borrow its ideas, the direction the post suggests is for Git platforms to offer server-side RPCs and to improve the negotiation protocol and sparse and shallow features.
My team merges only a few dozen times a day. Should I worry about this?
Not right now. Anthropic is dealing with 30,000 merges a day, 100 GB of history and 25 million CI checkouts a day, which is several orders of magnitude beyond a typical team.
But if you start using agents to write code at volume, it is worth checking the merge-count trend once a month, because it can grow faster than you expect.
Can I trust figures like 200x and 20x in the post?
They are self-reported by Anthropic on its own engineering blog, and the baseline is its previous Git-mirroring architecture, not a typical Git deployment. I found no independent third-party verification.
Treat them as results under their extreme scale and usage pattern, not as a promise your environment would see the same.
Does Claude rewriting the ingestion pipeline show AI can now build core infrastructure on its own?
The example only shows that on a well-defined task with an existing prototype to compare against, Claude produced a more efficient version. The post describes rewriting a prototype pipeline, which does not mean it can design an entire system independently.
Scion itself was built by seven people over five months, with Claude writing a large share of the code, but the design trade-offs were still the engineers' decisions.
Anthropic announced on its engineering blog that it built an in-house version control system called Scion and fully migrated its monorepo off Git in five months. The team was seven people, who also built a companion code-review tool called Antique, and Claude wrote a large share of the code. The motivation was blunt: in the post's own words, as merges per day grew more than tenfold, source control became its biggest development bottleneck.
By Anthropic's figures, daily merges rose from about 2,500 in May 2026 to over 30,000 by September, roughly 12x, which it largely attributes to code written by AI agents. The monorepo's main-branch history is close to 100 GB, the compressed working copy is over 25 GB, and CI alone performs about 25 million checkouts a day, before counting developer environments, agent sandboxes and research jobs. At peak there are several hundred Git mirrors, and with the old fetching approach daily Git traffic would exceed 600 PB. Anthropic's conclusion is that the properties that make Git excellent for distributed, offline work were working against it at this scale; its clients are mostly always-online agents and jobs that do not need a full local copy.
Scion uses a server-centric client-server model with tiered regional caches, each of which Anthropic says keeps a hit rate above 99%. By Anthropic's own account, Scion's CPU and memory footprint is 200x smaller than the previous Git-mirroring setup, CI and research checkouts dropped from minutes to seconds, and CI gained about 25% in CPU capacity. In another example, Claude rewrote the Git-to-Scion ingestion pipeline with no further instructions, using 20x less memory and running 4x faster. Antique can express semantic conditions on approvals, so a comment-only change can take a different path from a change touching sensitive logic. One caution: all of these figures are self-reported by Anthropic, and I found no independent third-party verification.
Anthropic says outright that Scion is by no means a suitable replacement for Git for general use, that its internal components are highly bespoke and hard for other organizations to adopt, and the post does not announce an open-source release. It argues its most useful contribution is sharing the thinking: Git platforms could offer server-side RPCs like Scion's and redesign the negotiation protocol and sparse and shallow features, so the Git community can apply the most successful parts of Scion to Git. (Some secondary coverage headlines it as open-sourcing Scion, which does not match the original post; go by the original.)
For most teams this story is not a call to drop Git but an early-warning signal: when agents start writing code in volume, what breaks first is often not the model quota but downstream processes such as merging, CI and checkouts. Measure three numbers: the growth curve of daily merges, the average checkout time in CI, and the load on your mirrors or caches. Handling them with shallow clones, caching and CI traffic splitting before they become bottlenecks is far cheaper than redesigning your architecture afterward.