git-ai: Two Days to 1,000 Stars – Open-Source Recreation of Anthropic's Scion

On October 13th, Anthropic published an engineering blog where it publicly described its internal version control system, Scion: a server-centered system designed for hundreds of coding agents that can read and write simultaneously and merge code. This system is not open-source. Two days later, on October 15th, developer feder-cr (Federico Elia) created a git-ai repository on GitHub. The first sentence of the README file was, “Anthropic built Scion… So I built git-ai: an open-source version of that design that anyone can run.” As of October 17th, there were approximately 1,000 stars (the GitHub search API reported 1057), achieving thousands of stars in just two days. It uses the MIT license and is written in Go language. This article will be divided into six sections, following the usual format.

1. Who is it?

The identity of gitai needs to be analyzed in two layers.

The base is a fork of GitLab Gitaly. Gitaly is GitLab’s Git RPC server. This chain of evidence is very clear in the repository: The NOTICE file starts with “The following components are included in Gitaly:”. In the cmd/ directory, there are the full set of original commands like gitaly, gitaly-backup, praefect, etc. The VERSION file states 19.5.0-rc3 (the version number of Gitaly). The LICENSE file has two lines of copyright: “Copyright (c) 2026 Federico Elia and the gitai contributors (modifications and additions). / Copyright (c) 2016-present GitLab Inc.”. The README states that Gitaly provides the underlying Git plumbing, and every Gitaly RPC from upstream can still be used. The ee/ directory from upstream that is not MIT-compatible is not included in this repository.

The new thing is called “graft”. Local statistics: there are 2833 git-tracked files in the entire repository, with Go code totaling about 576,000 lines (the majority of which was inherited from Gitaly). Of this, the “internal/graft” and “cmd/graft*” new directories account for approximately 75,000 lines. These are the core components of this open-source project: the graft CLI, the graft-cache caching process, the graft-verify verifier, the graft-bench performance testing tool, as well as a complete set of subsystems on the server side including land, changeset, derived data, resolver, and review.

There is one more detail that needs to be honestly explained: the git history of the repository has been squashed, and a shallow clone can only see one commit. Obviously, 75,000 lines of new code couldn’t have been written in just two days, but the development duration is unknown. It can only be understood as “long-term preparation followed by a one-time release.” The “Status” section in the README states “Version 0.1.0, the first public release.” Additionally, the repository contains two agent workflow files, AGENTS.md and CLAUDE.md. The project itself was organized with the intention of “using agents and allowing them to participate in development.”

II. Why is it now?

The direct reason for the emergence of gitai is Anthropic’s blog post “Redesigning source control at Anthropic” (published on October 13, updated once on October 15). This blog post digitized for the first time the pain points of source code management under agent-scale environments: in May 2026, there were approximately 2,500 merges per day; in September, it exceeded 30,000 merges per day, a 12-fold increase over four months. The main branch of the monorepo contained nearly 100GB of history, with compressed working copies starting at 25GB. There were about 25 million CI checksouts per day, which calculated to be 600PB+/day in raw git traffic. At peak times, hundreds of internal git mirrors had to be used. Traditional Git hosting is designed for “people to clone once, do work for a few hours, and push once.” Full cloning, merge queues, and client-side historical processing all become bottlenecks at this level. Scion’s solution was to move work to servers: clients remained online and accessed data as needed; historical tasks (like blame and path history) were processed and cached on the server; no queuing was required for operations; there were no complete repository copies on the server, allowing for horizontal scaling. Anthropic completed the migration in 5 months.

But Scion is internal and not accessible to the public. This led to the rise of open-source clones. Gitai isn’t the only one (on October 13th, someone already created openscion, but its popularity was limited; it received only 7 likes). However, it’s the fastest to run.

The other factor contributing to this popularity comes from a controversy. On October 14th, sunshowers, a former member of Meta’s source control team, posted (HN 425▲) stating that Scion “is heavily inspired by Mononoke” (Meta’s open-source version of its source control system): there are similarities in concepts and terms such as derived data and Bonsai changesets. Even the name “Scion” is a reversal of the syllables of “Bonsai” with “B” removed. At that time, Anthropic’s blog only thanked Google Piper and Meta Sapling. On October 15th, he added a second post (HN 251▲), confirming privately that Scion was “intentionally and blatantly copied from Mononoke,” and that there was overlap in personnel involved. This is based on sunshowers’ own statement, not independently verified. Subsequently, it was reported that Anthropic’s Nick G. responded on HN, adding clarification about the ownership, and there was also an official update at the top of the page: “Updated October 15th to include more details on the projects that pioneered many of the techniques we use in Scion.” The main blog post has HN story number 889▲ and was the top topic in the engineering community that week.

The significance of this controversy for the object being disassembled is that it turned “Scion’s design concept actually had open-source precedents (Mononoke)” into a public topic, essentially providing market education for all replicative projects. This is precisely the opportunity that gitai seized.

III. Mechanism Disassembly

Graft turned the designs described in Scion’s blog into something that can actually run. Please choose four of the most important points to discuss.

The first is that changes can be implemented without waiting in line. The merge queue of traditional hosting platforms has a serial bottleneck. UserLand’s approach with graft is to rebase the changes to the current branch’s tip, and then use compare-and-swap to update references: If CAS fails, it means someone has already implemented the change before, and the system will automatically retry, with a default maximum of 20 retries. Concurrent implementation on the same branch will also be combined into a single reference update. The baseline data in the documentation clearly shows this: When 20 agents implement changes on the same branch, each change averages about 10 attempts, with a p99 latency of 26 seconds.

The second is the changeset log. Each accepted referenced update is recorded in a changesets.jsonl file for each repository. It is written using flock for serial appending with fsync. The last line that gets truncated during a crash will be cut off when it’s appended next time. The serial numbers start from 1 and increase densely. The agent can subscribe to this stream to see in real-time what’s happening in the repositories. In the README, such monitoring agents are called superfans, and they can also report important events to Slack.

The third type is server-side derived data. blame, path history, ancestor relationships, and code searches are all calculated on the server. Content-addressing caching is used, with keys being SHA-256(kind, commit, path). Writing occurs through temporary files with atomic replacement of renaming, and each commit is counted only once. Therefore, the client does not need the complete history. Graft clone and graft sparse only materialize the paths you want.

The fourth is the pluggable resolver for conflict resolution. The protocol is versioned and vendor-neutral: it can be configured with a local command (receiving JSON from stdin) or an HTTP endpoint, with path whitelists and blacklists, actor whitelists, timeouts, and limits on the number of files. The AI resolver runs outside the server; the server itself never makes any calls to large models. This is a key principle of vendor neutrality emphasized repeatedly in the README. Commits resolved by AI will be annotated with the note “Graft-Resolved-By” for later auditing.

There is a key point in the security model: each agent has its own token, and identity cannot be impersonated by internal user IDs. E2E testing ensures this is maintained; which RPCs an agent can call is strictly defined in the code as an allowlist. Dangerous RPCs such as creating repositories from snapshots are permanently blocked for agents.

There are also two supporting mechanisms. The first is verification after implementation: graft-verify maintains a green reference. If the testing fails after implementation, it identifies the problematic changes and automatically reverts them, with the Graft-Auto-Revert annotation added. There is an upper limit on how many reverts can occur per hour to prevent consecutive errors. This transforms the slogan “merge first, then test” into a process with rollback guarantees. The second is semantic review rules: approval requirements can be configured based on the nature of the changes. For example, pure comment changes require less approval than logical changes. This is essential for scenarios where agents submit a large number of changes; human reviewers’ attention is inherently scarce. The cache layer has its own graft-cache daemon process. Regional layer caches store immutable objects. Before accessing each object, the ID (type plus length plus content) is recalculated. If it doesn’t match, the request is rejected. A batch of misses is combined into one upstream call.

IV. Numbers and Verification

The provided bench document from the warehouse shows actual measurements where 100 agents were deployed to a single branch simultaneously. The machine used was Intel Core Ultra 7 255H with WSL2, and the document specifies that noise was present: When batch deployment was turned off, on average, 56.94 attempts were made per change. Out of 500 changes, only 115 were successful, with 277 abandoned. The throughput was 126.6 attempts per minute. When batch deployment was enabled, the number of attempts per change decreased to an average of 1.00 attempt, with 392 changes successful. The throughput increased to 257.6 attempts per minute.

What’s more remarkable is that it doesn’t just report successes. The same document states that the acceptance criteria for phase 4a were not met: at both 50 and 100 agent sizes, the p99 latency was higher when batch processing was enabled compared to when it wasn’t. The Status section of the README clearly indicates that this is the first public version of Version 0.1.0; the interface may change before 1.0. End-to-end testing has only been conducted on a single machine, and multi-node behavior hasn’t been tested yet. The LIMITATIONS document under doc/graft lists four self-identifications: it’s not a托管 product, not a GitLab substitute, not an implementation of Scion, and it doesn’t constitute a security boundary.

Compare this with the normal state of the industry: most projects that rush to achieve thousands of stars in just two days only have a vision diagram in their README. This project was open-sourced with six stage design documents, fuzz and crash recovery test statements, and a bench report that clearly states “acceptance not met.” Its engineering quality is the strongest among similar projects.

V. Judgment

Let’s start with the conclusion: gitai is worth attention, but it currently addresses the issue of “Anthropic scale”. Anthropic itself also states in their blog that they don’t expect most organizations to encounter these problems in the near future.

Three observations. First, half of the “window” it hits is technology, and half is narrative. The controversy over Mononoke’s ownership turned “this design already has open-source precedents” into a public topic, essentially providing market education for all replicative projects. Gitai is the fastest among them; it received about 1,000 stars in just two days, much more than openscion (with only 7 likes on HN) which appeared on October 13th. A significant portion of this popularity is a transfer of attention from the controversy over Anthropic, not entirely related to the product itself.

Secondly, the choice of the GitLab fork is quite smart and also quite complex. It’s smart because it directly inherits Git RPC, repository management, and backup processes. The MIT license and declarations are also well-handled. However, it’s complex because it has to bear the complexity of the GitLab ecosystem. It requires Meson, Ninja, and compilation to bundle Git together. The difficulty of getting started means that it won’t become a popular tool in the short term.

Thirdly, what truly deserves to be learned from is several design decisions rather than the code itself: using CAS for local operations and batch processing instead of queues; using append-only JSONL with fsync for logs; making all AI capabilities portable outside the server, with pluggable resolvers; and hard-coding agent identities and permissions at the protocol level. These four points provide ready-made solutions for any team that needs to implement multi-agent collaboration infrastructure.

It’s important to clarify the risks: single-person leadership, historical data being obscured, inability to see the development process, interfaces in version 0.1.0 can change at any time, and even our own acceptance tests haven’t passed. It’s more fair to classify it as “highly valuable for design reference, but production usability is questionable”.

VI. Who can use it and how to use it

Multi-agent parallel writing to the same repository, teams that are already experiencing merge conflicts and queue congestion – this is its primary target audience. The quickstart script can set up the server, cache守护 processes, two agents, and perform one round of deployment in just one click. It takes half a day to complete the main process. The platform engineering team can only read the four documents under doc/graft: ARCHITECTURE, STORAGE, RESOLVE, and LIMITATIONS. They can copy the design judgments into their own plans without having to introduce code. Regular single-repository teams can continue using Git without any problems; this repository itself says the same.

For those who want to get started, remember three things: The storage core is disabled by default. Import from shadow mode and then switch to authoritative mode. Configure deterministic tools for resolver first, and add AI resolver later. Don’t treat it as a security boundary; make your LIMITATIONS clear.

Source of Information

• Repository itself: github.com/feder-cr/git-ai (README, NOTICE, LICENSE, go.mod, VERSION; 10-17 local clone verification; documents under doc/graft include ARCHITECTURE/STORAGE/RESOLVE/LIMITATIONS/BENCH/LAND-BATCHING)
• Anthropic official blog “Redesigning source control at Anthropic” (published on 10-13, updated on 10-15; all numbers from Scion)
• sunshowers.io: Two articles disputed regarding Mononoke (10-14, 10-15) and HN discussions (889▲/425▲/251▲/7▲, morning snapshot on 10-17)
• Stars and creation time: GitHub search API and repository page createdAt (morning snapshot on 10-17; number of stars still changing)