Anthropic, Cursor, GitHub, OpenAI: 4 Ways to Migrate Git to a New Platform

At agent scale, a system where every node hosts a full, autonomous copy of the Git history is no longer viable.

Anthropic, Cursor, GitHub, and OpenAI agree on this point. Each has begun evolving its version-control system by abandoning the purely decentralized model.

Anthropic abandons Git for a proprietary system

On its internal monorepo, Anthropic has shifted from approximately 2,500 merges per day in May 2026 to over 30,000 in September. With a main history around 100 GB and nearly 25 million daily extracts for CI, the traditional use of Git would have required transferring more than 600 PB of data per day. The workaround of running hundreds of mirrors and snapshots of repositories on object storage had become unmanageable.

Anthropic has chosen to break with Git. It replaced it with a homegrown system named Scion, developed in five months.

Thus, the decentralized model is out. The server handles the heavy operations (merges, rebases, creating commits…) while the local client is reduced to a lightweight layer managing a bounded cache and on-demand materialization of files on disk.

Unlike a Git commit pointing to a full tree of objects, Scion’s changeset stores only the list of files modified relative to the first parent. This list is associated with content-addressed pointers to compressed blobs.

An asymmetric approach using changesets and hierarchical caches

From Git, Scion also eliminates packfiles. It uses, in parallel, no fully materialized copy of the repository. Creating a changeset is done in time proportional to the size of the modification — not the size of the repository. Global references (branches, tags) are strictly discouraged outside the main branch or versions. Their updates are performed by CAS (compare-and-swap) on a Spanner baseline.

To calculate quickly the blame or the graphs of commits, Scion generates “derived data” (skip lists, path indexes) defined recursively and computable on demand. The system exposes these primitives via API. CI and internal tools can thus issue queries without local cloners.

The client communicates via a socket with a node daemon that queries regional memory caches. These caches are fed by authority servers backed by Spanner and object storage. A hierarchy that isolates failures and eliminates Git negotiation protocols.

Anthropic claims that this infrastructure uses 200 times fewer compute and memory resources than its former Git fleet. It adds that CI gained 25% CPU capacity, with checkouts now taking just a few seconds.

Cursor uses a WAL-S3 as a single source of truth

Cursor preserved Git’s storage format and native tooling on local NVMe disks. To overcome Spokes’ limitations (GitHub’s historic replication architecture), it designed an alternative engine named Continuity. It applied it to its monorepo and to a fleet of micro-repositories.

Its architecture centers on a S3-specific concept: Write-Ahead Logs (WAL). In broad terms, these involve storing multiple objects in a single file sequentially. Here, every push takes the form of a distinct WAL entry. No push is acknowledged until it is persisted on S3. A WAL index file updated via CAS linearizes each transaction.

The local NVMe replicas are only caches rehydrated from the WAL. Repository locality does not depend on a central relational database. If a node fails or a repository is not present locally, it is materialized from the WAL.

Any node can receive a write and act as primary. The atomicity of CAS on S3 guarantees integrity. Read propagation happens via UDP gossip, with each replica cross-checking its state against the source of truth.

Continuity scales to 120 pushes per second on S3 Standard; to more than 300 with S3 Express One Zone. It then hits the intrinsic speed limit of Git’s on-disk compaction. In reads, the system demonstrated linear ramping up to 100 replicas without impacting writes.

OpenAI opts for causal coherence…

Over two years, the volume of commits landing on OpenAI’s master branch of its monorepo had roughly increased 25-fold. The reliability of version control had fallen below 90%. In 10 weeks, the company built Pando.

This back-end rejects the idea that a server must provide a coherent state of all branches at a single instant during a clone or fetch. Updates to each branch are independent and serializable individually, but Pando replaces the global snapshot with a causal-consistency model. A client fetching a branch respects the author’s history who created it, without the system enforcing a global interleaving order with unrelated branches. Two clients reading different branches at the same time may thus see time-shifted versions.

Traditionally, each fetch requires the server to dynamically calculate the difference between the objects the client holds and those requested, then compress a bespoke packfile. Pando reuses immutable preexisting packfiles. Servers therefore no longer have to recalculate deltas on the fly.

During a push, the packfile sent by the client is validated in a single pass and streamed directly to object storage, without local unpacking. A transaction records a “reference version” in the metadata store and atomically toggles the branch pointer. During the push negotiation phase, Pando does not announce the entirety of its branches. This avoids creating packs that are too interdependent or too fragmented.

… and for reusable packfiles

To transfer data, Pando uses packfile-url, a Git directive OpenAI refined upstream in the open-source project. During a fetch, the main HTTP response returns an empty packfile along with a list of URIs pointing to the required packfiles. Clients download these packs from Express, a distributed regional caching service. This maximizes network bandwidth usage without taxing server CPU.

Each push generates an L0 pack. Background processes geometrically cluster all packs into higher layers (L1 to L4) to improve compression and accelerate extractions.

OpenAI notes that Pando has reduced median push latency by nearly 80%. And it enables the delivery of about 1 PB of Git data per day with “a handful” of CPU cores.