Anthropic Built a Git Alternative in 5 Months With 7 Engineers and Claude

Anthropic Built a Git Alternative in 5 Months With 7 Engineers and Claude

Git has been the dominant version control system for software development for nearly two decades. However, Anthropic has reportedly built an internal alternative called Scion, designed specifically for the demands of large-scale AI-assisted software engineering.

According to Anthropic’s engineering account, a team of just seven engineers used Claude extensively to develop Scion, the associated code review system Antique, and several supporting tools over approximately five months. The project culminated in migrating Anthropic’s monorepo from Git to Scion.

The motivation was not simply to replace a familiar developer tool. Anthropic’s AI-driven development workflow had expanded to a scale at which its existing source control infrastructure struggled to keep pace. With automated agents generating and submitting code at unprecedented rates, the company needed an architecture designed around continuously connected clients, centralized computation, and horizontally scalable data services.

The project illustrates two important trends: AI agents are changing the infrastructure requirements of software development, and AI-assisted engineering is making it possible for small teams to build complex internal systems faster than traditional workflows might allow.

🚀 Why Anthropic Built an Alternative to Git

#

Anthropic’s primary motivation was the rapid growth of its code development and integration workload.

According to the figures cited in its engineering account, the company averaged approximately 2,500 code merges per day in May, rising to more than 30,000 per day by September. That represents a roughly 12-fold increase in four months.

As coding agents become more productive, source control, code review, testing, and deployment infrastructure must process the resulting changes without becoming bottlenecks.

When Git’s Distributed Architecture Becomes a Constraint

#

Git is a distributed version control system. Each conventional clone contains a local repository with commit history and the objects needed to support operations such as diffing, branching, history inspection, and offline development.

This design is extremely effective for most software projects. Developers can work independently, inspect history without network access, and exchange changes when connectivity is available.

However, the same architecture can become expensive when a repository grows to an exceptional size and thousands of automated tasks repeatedly access its contents.

Anthropic reported that its main-branch history approached 100GB, while a compressed working copy exceeded 25GB. Its continuous integration infrastructure performed approximately 25 million checkouts per day, excluding additional activity from development environments, agent sandboxes, and research workflows.

Fetching all the required repository data independently for these operations could generate more than 600 petabytes of daily data traffic, according to the company’s estimates.

The resulting challenge was not simply repository size. It was the aggregate cost of repeatedly transferring, storing, and processing repository data across a large fleet of automated workers.

Why Existing Git Scaling Techniques Were No Longer Enough

#

Git provides several mechanisms for reducing repository transfer and storage costs, including shallow clones, sparse checkouts, and partial clones using promisor remotes.

Large organizations also commonly deploy internal Git mirrors and distribute repository snapshots through object storage.

Anthropic had already adopted these approaches. At peak load, it reportedly operated hundreds of internal Git mirror servers.

These measures improved performance, but they also introduced operational complexity. Repository snapshots could fall behind the latest main-branch state, while partially cloned repositories still required additional infrastructure to support history-dependent operations such as diff and blame.

The central architectural question eventually became straightforward:

If nearly every source control client is an online AI agent or automated task, does every client need the capabilities and repository data of a traditional distributed Git clone?

Scion was Anthropic’s answer to that question.

🧠 Six Design Principles Behind Agent-Scale Source Control

#

Scion was designed around Anthropic’s actual workload rather than attempting to reproduce every feature of Git. Its architecture assumes that clients are generally connected, repository data is served centrally, and most expensive operations should be performed by scalable backend services.

The approach also draws on prior work in large-scale source control, including Google’s Piper and Meta’s Sapling.

1. Always-Connected Clients

#

Git supports offline development by allowing each clone to maintain its own repository history and objects.

Scion instead assumes that clients can reach a source control service when they need repository data. Clients request the specific objects and operations required for their current task rather than maintaining a complete local repository.

This approach fits automated agents that run in managed compute environments and typically need reliable network access to execute development tasks.

The trade-off is that clients become more dependent on the availability and performance of the source control service. Offline operation is no longer the default architectural assumption.

2. Server-Side Computation

#

In Git, clients can perform many repository operations independently. Scion shifts much of this work to the server, including commit creation, merging, rebasing, history queries, and blame calculations.

The client primarily manages the working copy, monitors file changes, maintains a bounded object cache, and exposes developer-facing commands.

This separation reduces the amount of repository data and computation required on individual workers. It also creates a shared service layer that can optimize repository operations once for many clients.

3. Source Control as an API Platform

#

Traditional CI systems and development tools often need a local repository checkout to answer questions about commit ancestry, file history, or differences between revisions.

Scion exposes source control operations through APIs, allowing internal tools to query repository state without maintaining a full repository copy.

For example, a CI task that needs to calculate a diff between a commit and its merge base can request the result directly from the service instead of downloading repository data first.

This approach is particularly useful for automated bisection, rollback pipelines, code analysis, and other workflows that require repository metadata but do not need a working directory.

4. Horizontal Scalability Across Components

#

Scion distributes repository data rather than requiring every server to maintain a fully materialized copy of the entire repository.

Its components can scale independently according to demand. Content-addressed objects can be cached across servers because an object’s contents do not change after it is created.

This reduces the need for extensive coordination between servers when serving existing repository objects.

The architecture also avoids making repository-wide packfile maintenance a central operational requirement, although it still needs to manage derived metadata, object availability, and the underlying storage systems.

5. Lightweight Commits and Minimal Coordination

#

In a conventional Git workflow, developers create commits locally and push them to a remote repository. Operations such as rebasing and merging can involve updating references and coordinating changes through shared repository state.

Scion performs commit creation and related operations on the server. Its design aims to keep the cost of creating a changeset proportional to the size of the modification rather than the total size of the repository.

Scion still supports references such as branches and tags. However, creating and retrieving changesets does not depend on moving references, allowing reference updates to remain separate from changeset creation.

According to Anthropic’s description, reference updates can use a compare-and-swap operation on a single row in Spanner, reducing coupling between repository mutations and global reference management.

6. Sparse and Virtualized Checkouts

#

Large-scale automation frequently needs only a small portion of a repository.

Scion supports sparse checkouts, which materialize selected directories, and virtualized checkouts, which retrieve files as they are accessed.

This avoids downloading and storing data that a task never uses.

The distinction is important for AI coding agents, CI workers, and research tasks that may execute briefly and require only a small subset of a massive monorepo.

For developers exploring related infrastructure concepts, KAD8’s technology coverage provides additional technical reading on software and computing systems.

⚙️ How Scion’s Architecture Works

#

Scion’s performance characteristics come from the combination of its changeset model, derived data structures, content-addressed storage, and hierarchical caching system.

Rather than treating the repository as a complete collection of objects that every client must maintain, Scion separates the recording of changes from the indexes and metadata required to query those changes efficiently.

Changesets: A Different Model for Recording Commits

#

Scion’s basic unit of work is the Changeset, which Anthropic describes as a record in a write-ahead log.

A changeset preserves much of the information associated with a Git commit, but the underlying data organization differs.

A Git commit points to a tree object representing the repository state. A Scion changeset instead records the files modified relative to its first parent, together with content-addressed references to compressed file contents stored in object storage.

Changesets are created server-side and become accessible throughout the system after creation.

This model is designed to make recording new changes efficient even when the repository contains a very large amount of historical data.

Because creating a changeset does not require distributing a packfile or updating a global reference structure, the operation can remain largely independent of unrelated repository activity.

Derived Data for History and Code Navigation

#

Changesets efficiently record what changed, but additional structures are needed to answer questions such as:

• Which commit last modified a particular line?
• How has a file evolved across revisions?
• Which commits are ancestors of a given changeset?
• Where did a file move or originate through a copy operation?

Scion addresses these requirements with derived data: indexes and metadata computed from the changeset graph.

Each derived data type can use recursive definitions based on the corresponding data associated with a parent changeset.

This design provides several advantages.

First, new indexes can be introduced when additional query operations need acceleration. Second, derived data can be computed eagerly or lazily according to access patterns. Third, clients remain insulated from the internal implementation of these structures.

As a result, the server can evolve its indexing strategy without requiring clients to understand every underlying data structure.

Anthropic has reportedly added additional derived data types over time, including file-copy detection and path-oriented search indexes.

Content-Addressed Storage and Horizontal Scaling

#

Scion uses content-addressed objects, meaning that an object’s identity is derived from its content.

Once written, the content associated with a given object identifier is immutable. This property makes caching more straightforward because servers do not need to coordinate every cache read to determine whether an existing object’s contents have changed.

A Scion server cluster exposes APIs for retrieving changesets, calculating diffs, finding merge bases, and obtaining file contents.

The servers can compute derived data when necessary and persist results in Spanner or cloud storage. Because many requests target the same immutable objects, caching can absorb a large proportion of repeated traffic.

This architecture reduces the need for every server to hold a complete copy of the repository and makes it possible to scale different parts of the service independently.

🔄 Scion’s Client and Caching Infrastructure

#

Scion’s scn client uses a different object-fetching protocol from conventional Git clients.

Instead of asking the server to negotiate a packfile based on objects the client already possesses, the client requests specific directory trees and blob objects.

The client begins with a root tree, checks which objects are missing from local storage, and recursively requests the required objects. Tree data is retrieved before file contents, allowing the client to avoid fetching blobs belonging to directories it does not need.

Because each request identifies an immutable object, intermediate caches can serve it without consulting the authoritative server on every request.

The Three Main Components

#

Anthropic describes a layered architecture consisting of scion-daemon, scion-cache, and scion-server.

scion-daemon: Node-Level Caching

#

The daemon runs on compute nodes and maintains an object cache shared by tasks on the same machine.

This sharing is valuable when multiple CI jobs or AI agents access the same monorepo. Instead of independently downloading identical objects, tasks can reuse data already cached on their node.

The daemon also loads a periodically updated snapshot during startup, helping reduce the amount of data that must be fetched repeatedly.

scion-cache: Regional Object Delivery

#

Regional cache servers deliver tree and blob objects to daemons.

Anthropic describes these caches as streaming objects directly from memory in formats that the receiving daemon can write to disk. They avoid expensive operations such as computing missing client objects or performing differential compression.

When a requested object is absent, the regional cache retrieves it from the authoritative service.

This division of responsibilities keeps the cache layer focused on fast object delivery rather than repository computation.

scion-server: Authoritative Repository Operations

#

The authoritative service handles repository operations and accesses persistent storage when necessary.

The components share compatible RPC interfaces, allowing them to communicate through common service contracts while preserving distinct operational roles.

Anthropic also enforces access boundaries between tiers to isolate failures. For example, a regional cache outage should not cause uncontrolled traffic to overwhelm the authoritative servers.

This is an important reliability consideration for infrastructure serving millions of requests: a cache failure should degrade a limited part of the system rather than trigger a cascading outage.

Reported Performance Improvements

#

Anthropic reports that the cache layers achieve hit rates above 99% without maintaining extensive long-term state.

The company also reports substantial improvements compared with its previous Git mirroring infrastructure:

These figures are Anthropic’s reported results, not independently reproduced benchmarks. Actual performance would depend on repository characteristics, cache locality, workload patterns, and the baseline configuration.

Nevertheless, the results illustrate the potential value of eliminating redundant repository materialization and moving source control operations into a shared service.

🛡️ Monorepo Security and Code Review

#

Performance was not the only consideration in Scion’s design. A massive monorepo also introduces access-control and compliance challenges, particularly when many automated agents can inspect and modify code.

Anthropic built access controls and per-directory permissions into Scion to restrict access to sensitive parts of the repository while preserving the benefits of a shared codebase.

The associated code review system, Antique, reportedly supports semantic approval constraints. For example, a policy could distinguish a comment-only change from a modification to sensitive application logic.

This approach can help align review requirements with the risk associated with a change rather than relying exclusively on file paths or broad repository permissions.

For AI-generated code, such controls become increasingly important. Higher code-generation throughput is valuable only if review, authorization, testing, and deployment safeguards can keep pace.

🤖 How Claude Changed the Development Process

#

Anthropic developed Scion during a period when newer Claude models were becoming available internally. The company says those models both increased the demand for its infrastructure and accelerated the implementation process.

One example involved the initial Git-to-Scion migration pipeline. Engineers had built an early implementation that they considered reasonably effective. After an internal Claude model became available, Anthropic asked Claude to rewrite the program.

According to the company’s account, the rewritten implementation used approximately 20 times less memory and ran four times faster while preserving implicit requirements involving import ordering and data structures.

This example illustrates an important distinction between generating code quickly and improving an existing system. The latter requires preserving behavioral constraints while changing implementation details.

Seven Engineers, Five Months

#

Anthropic reports that seven engineers developed Scion, Antique, and roughly half a dozen supporting systems in about five months.

The result was not simply a prototype. The project included the infrastructure required to migrate an existing monorepo and support ongoing development operations.

AI assistance accelerated implementation, but engineers still had to define architectural boundaries, determine which trade-offs were acceptable, and verify that the system behaved correctly.

The project therefore provides a useful example of how AI can change engineering productivity without eliminating the need for experienced technical judgment.

Code Quality, Testing, and Performance Optimization

#

Anthropic says Scion became one of its most thoroughly tested and guarded codebases.

The team developed isolated, repeatable simulation tests for complex infrastructure interactions and source control operations. It also incorporated fuzz testing and rate limiting.

Claude reportedly identified performance problems that led to meaningful improvements, including a missing index in a commit-ancestry query algorithm.

These results demonstrate how AI coding tools can contribute beyond initial implementation. They can help engineers inspect unfamiliar code, explore optimization opportunities, and generate tests for complex behavior.

However, the quality of these contributions still depends on the testing environment, the quality of the specifications, and the ability of engineers to recognize incorrect or unnecessary changes.

Why Human Engineers Still Matter

#

Anthropic’s engineers reportedly found that Claude could write code faster than they could. Even so, the team remained responsible for deciding what should be built and which implementation constraints mattered.

One challenge was preventing the model from solving the wrong problem in a technically plausible way.

For example, when asked to determine when a change entered the main branch, an agent might attempt to scan a linear commit history rather than query the code review system directly.

The implementation could appear reasonable while violating the intended architectural approach.

Anthropic also used adversarial code review, in which AI systems searched for defects and potential weaknesses. Although this identified useful issues, the approach could sometimes overemphasize minor risks or encourage excessive defensive code.

Experienced engineers therefore continued reviewing changes with a focus on intent, system behavior, and architectural consistency.

The broader lesson is that AI-assisted development shifts engineering effort toward specification, system design, verification, and technical direction. It does not remove the need for those activities.

📈 How AI Agents Could Change Monorepo Workflows

#

Scion also prompted Anthropic to reconsider software development practices that were designed around human coding speed.

Traditional merge queues coordinate changes and tests to preserve repository consistency. However, when hundreds or thousands of AI-generated changes are produced while CI is running, the queue itself can become a bottleneck.

Anthropic argues that globally coordinating every change becomes increasingly difficult at agent scale.

One response is to invest more heavily in post-merge and pre-deployment testing, automated conflict resolution, and rapid rollback mechanisms. In this model, some conflicts can be resolved automatically before they significantly disrupt human workflows.

This does not mean that merge queues or pre-merge checks are universally obsolete. The appropriate design depends on the cost of a failed change, the reliability of automated testing, the ability to isolate changes, and the consequences of inconsistent intermediate states.

For many organizations, a gradual evolution of existing CI and source control infrastructure will be more practical than replacing the entire version control system.

🔮 What Scion Means for the Broader Developer Ecosystem

#

Anthropic does not position Scion as a general-purpose replacement for Git. Its architecture is tailored to unusually large monorepos and workloads dominated by automated agents.

For smaller projects, Git’s distributed model remains highly effective. Offline development, mature tooling, widespread hosting support, and a large ecosystem make it a difficult system to replace without a compelling operational need.

Scion’s value becomes clearer when the cost of maintaining local repository copies exceeds the benefits they provide.

Lessons That Could Influence Git Infrastructure

#

Even organizations that continue using Git can adopt some of Scion’s architectural ideas.

Potential improvements include:

• Server-side repository APIs: Expose history, diff, ancestry, and blame operations without requiring every client to maintain a full clone.
• More efficient object delivery: Improve how clients request and cache individual repository objects.
• Smarter sparse checkouts: Avoid transferring data that a task never reads.
• Shared node-level caches: Let multiple CI jobs and agents reuse repository objects.
• Incremental metadata processing: Compute indexes and derived data only when needed.
• Agent-aware CI pipelines: Reduce unnecessary serialization and improve the handling of large volumes of automated changes.

These ideas do not require abandoning Git’s fundamental model. They can inform improvements to hosting services, CI infrastructure, repository caching, and developer tooling.

For additional developer resources and infrastructure-related technical coverage, see PUDN’s technology and programming resources.

Will Other Companies Face the Same Problems?

#

Anthropic suggests that other organizations may encounter similar scaling pressures as AI coding tools become more widely adopted.

The timing will vary significantly. Repository size, agent usage, CI architecture, code review policies, and the rate of change all affect when source control becomes a bottleneck.

A company with a conventional monorepo and moderate automation may never need a system like Scion. An organization running thousands of concurrent coding agents against a shared codebase may face very different constraints.

The important takeaway is not that every company needs a new version control system. It is that source control infrastructure should be designed around actual workload patterns rather than assumed to scale indefinitely without architectural changes.

📰 Conclusion: AI Is Reshaping Software Engineering Infrastructure

#

Anthropic’s Scion project demonstrates how AI-assisted development can influence both the speed of software implementation and the architecture of the systems that support it.

A seven-person team reportedly built a new source control platform, a code review system, and supporting infrastructure in approximately five months. The migration addressed a concrete operational challenge: traditional repository workflows were becoming expensive under the pressure of rapidly increasing AI-generated code changes.

Scion’s design replaces many client-side repository operations with server-side APIs, immutable content-addressed objects, derived metadata, and a horizontally scalable caching architecture. Anthropic reports significant improvements in resource consumption and checkout performance after adopting the system.

The project also offers a broader lesson for AI engineering. When code generation accelerates, bottlenecks can move from implementation to testing, source control, code review, and deployment. Organizations must optimize the entire development lifecycle rather than treating faster code generation as the only measure of productivity.

Git is not obsolete, and Scion is not necessarily the right choice for most teams. But Anthropic’s experience suggests that as agent-driven development scales, some long-standing assumptions about source control and software delivery may need to change.