Anthropic’s AI Coding Boom Hit a Git Bottleneck: Why It Built Its Own Version Control for 30,000 Merges a Day
Quick summary: the Git bottleneck behind Anthropic’s AI coding boom
- AI changed the bottleneck: Anthropic says daily merged changes rose from about 2,500 in May 2026 to more than 30,000 in September, straining source control and CI.
- Scion is server-centred: It moves history queries, commits and merges to online services, while clients fetch only the files they need.
- The gains are company-reported: Anthropic reports much faster checkouts and lower infrastructure use, but the figures have not been independently audited.
- Git still fits most teams: Scion trades offline, self-contained clones for central services, and Anthropic says its design targets exceptionally large, agent-heavy monorepos.
Anthropic’s AI coding boom hit a Git bottleneck inside its own monorepo. When agents can produce changes faster than infrastructure can check out, review and test them, the tools around coding become the constraint.
Anthropic responded by building Scion, an in-house source control system, and migrating its monorepo from Git in five months. A seven-person team also shipped related tools, including a code review interface called Antique. The company says daily merged changes rose from around 2,500 in May 2026 to more than 30,000 in September. These figures and the results below come from Anthropic’s own engineering account, not an independent audit. Read the original engineering post.
Why the Git bottleneck appeared at Anthropic
Git’s distributed design is a strength for most projects. Each clone contains repository history, so a developer can inspect changes, create commits and work offline. But at Anthropic’s scale, repeatedly distributing and maintaining repository data for automated jobs became expensive.
Anthropic says its main-branch history was nearly 100 GB, its compressed working copy exceeded 25 GB, and CI alone performed around 25 million code checkouts per day. The company had already used shallow and sparse clones, stored snapshots, and hundreds of internal Git mirrors. As the merge rate rose, keeping those mirrors current and operating them became harder.
The workload shaped the solution. Anthropic says most clients were agents and jobs that were online by definition. It chose to build around that assumption instead of preserving Git’s full offline, self-contained model.
How the Git bottleneck led to Scion
| Design question | Git | Scion, as Anthropic describes it |
|---|---|---|
| Where work happens | Most repository operations can happen in a local clone. | Servers handle history queries, commits, rebases and merges. |
| Offline work | Clients can use local history while disconnected. | Clients rely on reachable services for core source control operations. |
| Repository data | Clones hold substantial repository data and history. | Clients fetch requested objects and can use sparse or virtual checkouts. |
| Best fit | Most projects that value a distributed, familiar workflow. | Anthropic’s unusually large monorepo and high volume of online agents and jobs. |
This is a workload-specific design choice, not proof that Git is generally too slow for AI coding. Git’s offline capability is valuable to many teams. Scion accepts more dependence on central services in exchange for less duplicated repository data and more direct integration with automated tools.
How Scion serves agents and CI
Scion makes source control available as a service. A client can ask a server for a diff, blame information or a merge base without keeping a full local repository. The server can also create commits, rebases and merges.
When a job needs files, Scion supports sparse checkouts for selected directories and virtual checkouts that fetch files on demand. Its changesets record which files changed and point to compressed content stored separately. Additional indexes support queries such as file history and blame.
Anthropic describes a tiered cache: a machine-level daemon shares repository objects among jobs on the same node, regional caches serve common requests, and authoritative services fetch missing data from Spanner or cloud storage. Because objects are content-addressed and immutable, caches can serve them without coordinating every read.
This approach connects source control to the rest of the development environment. For another example of infrastructure built around agent workloads, see our article on how Google AX uses Kubernetes and snapshots to run AI agents.
What performance gains does Anthropic report?
Anthropic reports three headline results for Scion:
- More than 99% cache hit rates across each tier.
- Two orders of magnitude faster checkouts for CI and research jobs, changing the reported experience from minutes to seconds.
- 25% more CI CPU capacity, with Scion’s infrastructure footprint 200 times smaller than the previous Git mirroring setup by CPU and memory requirements.
These figures help explain why Scion works for Anthropic. The post does not provide an independently audited benchmark or enough detail to reproduce the measurements, so other organisations should not assume they would see the same gains.
Higher change volume also affects testing and integration. Anthropic says it could not effectively use a global lock to serialize its merge queue. It invested instead in automated testing before deployment and after merge, accepting that concurrent changes can conflict. The company says Claude can often repair conflicts quickly, but it does not quantify the resulting rework or failure rate.
What the Git bottleneck reveals about merge volume
A merged-change count measures throughput. It does not tell us how many changes were written by people or AI, how much user value they delivered, or how much maintenance they will require.
Anthropic separately said more than 80% of the code it merged was authored by Claude as of May 2026, and that its typical engineer merged eight times as much code per day in the second quarter of 2026 as in 2024. Those are company-reported output measures, not independent proof of a matching rise in productivity or quality. Anthropic’s account of its internal coding measures provides further context.
Evidence from other settings can look different. A randomized METR study of 16 experienced open-source developers completing 246 tasks found that early-2025 AI tools increased completion time by 19% on average. That study did not test Anthropic’s later models or internal workflow, but it illustrates why output, speed and software quality should be measured separately. Read the METR study.
Why engineers still mattered
Anthropic says engineers chose the architecture, set system constraints and reviewed the intent of changes. It describes agents that tried to scan commit logs instead of querying the review system, and cases where adversarial review encouraged unnecessary complexity. Engineers had to steer the work back to the intended design.
That is a useful reminder: generating code faster does not remove the need to decide what belongs in a system, set boundaries and evaluate trade-offs. Our guide to whether an AI agent can ship code without skipping the hard parts explores the work between generated code and a safe release.
Should other teams replace Git?
For most teams, no. Anthropic says Scion is not a general-purpose Git replacement. Its design makes sense for exceptionally large monorepos with huge volumes of online agents and automated jobs. Adopting it would also mean migrating surrounding tools such as code review, code search and CI.
The broader lesson is to measure where work moves as AI-assisted development scales. If checkouts, merge queues or testing become the constraint, targeted improvements to caching, sparse retrieval or CI scheduling may help. Anthropic’s story is a case study in infrastructure adapting to a particular workload, not a prescription for every codebase.