OpenAI Is Rebuilding Git, Too

On October 13, Anthropic published Redesigning source control at Anthropic, introducing Scion, its in-house version control system. I wrote about it at the time in Anthropic’s In-House Version Control: Scion. The core issue was that Claude produces code so fast that Git, builds, and CI, infrastructure originally built for human developers, had started to become bottlenecks.

Less than a month later, on November 2, OpenAI published its own technical post, Scaling Git at OpenAI, introducing Pando, the Git backend they built.

The two companies ran into very similar problems: AI agents have dramatically increased the concurrency of software development, and source control systems are struggling to keep up with the pace of code production. But their solutions differ noticeably.

Anthropic chose to redesign version control from scratch and fully migrated its monorepo to Scion. OpenAI kept the Git protocol and client, and redesigned the server side so that existing Git can support large-scale concurrent agent development.

Codex Is Putting Git Under More Pressure

Much like Anthropic, OpenAI found that as AI coding agents took on a large share of development, its existing version control infrastructure struggled to keep up with ever-growing concurrency.

At Anthropic, this shift came mainly from Claude; at OpenAI, the rapid growth in code production was driven by Codex.

In the past, an engineer might maintain a few branches at once. Now, with Codex, a single engineer can have multiple agents working on different tasks in parallel. Each agent may independently commit code, push branches, and trigger CI, and each CI run may launch multiple jobs that repeatedly fetch the same code.

As a result, both of Git’s core operations came under pressure:

• Push: Large numbers of agents pushing to different branches at the same time require the server to handle highly concurrent writes.
• Fetch / Clone: CI, agent sandboxes, and development environments fetch code constantly, requiring the server to have extremely high data distribution capacity.

OpenAI notes that starting in late 2025, its monorepo infrastructure gradually fell behind demand. Pushes and fetches slowed down, merges failed, and system reliability at times dropped below 90%.

They ultimately built Pando, a brand-new implementation of a Git server backend.

According to OpenAI, Pando now handles all development on the OpenAI monorepo, with the following results:

These figures come from OpenAI’s production environment and performance validation. Note that 10 Gbps is the network throughput validated within their infrastructure; it doesn’t mean every Git client will reach that speed.

How Is Pando Designed?

Let’s start with Pando’s overall architecture.

Figure: Simplified logical architecture of Pando; the background compaction flow is not shown. Based on OpenAI’s official post.

Pando keeps Git’s existing client protocol and object model, but redesigns the server’s data storage, concurrency control, and data distribution.

Architecturally, Pando’s core can be divided into several parts:

• Git service layer: Handles client requests such as push and fetch, including object validation, ref updates, and fetch planning.
• Metadata store: Manages refs, version information, and the dependencies between packfiles.
• Object storage: Stores immutable Git packfiles, avoiding reliance on any single server’s local disk.
• Express regional cache: Caches frequently accessed packfiles, reducing object storage reads and repeated data transfer.

In addition, Pando runs background compaction jobs that merge and reorganize many small packfiles, reducing the number of files a client has to process during a fetch.

On top of this architecture, Pando solves three main problems: how different branches can be written in parallel, how existing packfiles can be reused, and how large numbers of packfiles can be organized and queried efficiently.

1. Relaxing Consistency So Branches Can Be Written in Parallel

A Git repository contains two key kinds of data: objects and refs.

Objects store file contents, directory structure, and commit history. They are identified by content hashes and are immutable once created.

Refs, on the other hand, are mutable. For example, refs/heads/main points to a particular commit.

For a distributed Git service, the hard part is keeping objects and refs consistent.

Traditional multi-replica architectures can coordinate replicas through three-phase commit (3PC), or order updates through a shared WAL. These approaches share a common problem: even if two agents are modifying completely different branches, global coordination can still make them contend with each other.

Suppose three agents are working at the same time:

Agent A → feature/payment
Agent B → feature/order
Agent C → feature/search

There are no direct dependencies between these three branches, so in theory they could all push fully in parallel.

But if every ref update has to go through the same shared log or global coordination process, unnecessary waiting occurs.

Pando’s approach is to adopt causal consistency, relaxing the requirement that the whole repository be consistent at a single point in time.

Different refs can be updated independently; only operations that modify the same ref at the same time need to contend.

For example, if two agents update feature/payment simultaneously, Pando uses a Compare-and-Swap-style mechanism to control concurrency and prevent one update from accidentally overwriting the other.

The trade-off is that when a client reads multiple branches at once, it may see versions from different points in time. For instance, it might see an old version of foo and a new version of bar.

But for most Git workflows, what developers actually need is the update order of a given branch, plus the complete history required to read that commit. They rarely need a globally consistent snapshot of every branch in the repository.

With this trade-off, Pando eliminates a large amount of coordination cost between branches.

2. Reusing Packfiles to Reduce Redundant Computation

This is one of the most valuable parts of Pando’s design.

Git uses packfiles to compress, store, and transmit multiple objects.

In a traditional Git fetch, the client tells the server:

• have: which commits I already have.
• want: which commits I want to get.

The server uses both to compute which objects the client is missing, then generates a corresponding packfile.

The problem is that even if multiple clients want the same commit, as long as their local histories differ, the server may need to compute and generate a different packfile for each of them.

In large-scale CI, this means a huge amount of redundant CPU and disk I/O.

Pando changes this flow.

When a client pushes, Pando validates the uploaded content and, at the same time, writes the packfile directly to object storage, recording in metadata which historical versions it depends on.

When other clients later fetch, the server uses the versions they already have to find packfiles that cover the target history, and lets the client download them directly.

In other words, packfiles produced during a push can be used directly to serve other clients’ fetches.

To make this work, Pando also changed how the Git server advertises refs to pushing clients.

A traditional Git server usually advertises many refs to help the client minimize the data it uploads. But this makes the resulting packfiles depend on all sorts of different histories, reducing their reusability.

By default, Pando advertises only the designated trunk branch to pushes of new feature branches, limiting the shared history a packfile can depend on.

That way, any client that already has the corresponding trunk history can use the packfile directly.

The cost is that clients may upload or download some objects redundantly. But for OpenAI’s workload, this cost is small:

• The median push packfile is under 20 KiB.
• The P99 size is under 3 MiB.

Compared with the reduced server-side computation and higher cache reuse, this extra transfer is acceptable.

3. Compacting Packfiles with LSM Tree Ideas

Reusing packfiles directly introduces a new problem.

If every push produces its own packfile, then for a repository with tens of thousands of commits a day, a client might need to download tens of thousands of small files just to catch up with the main branch.

Pando borrows the compaction idea from LSM trees.

Each push produces an L0 packfile, and background jobs organize multiple small packfiles into covers spanning larger version ranges, progressively merging and compacting them.

L0: [P1] [P2] [P3] [P4] [P5] [P6]
          ↓ Compaction
L1: [    Cover A    ] [    Cover B    ]
          ↓ Compaction
L2: [           Cover C             ]

Figure: Illustration of Pando’s layered packfile organization; actual cover sizes and level relationships depend on the real configuration.

OpenAI’s monorepo currently goes up to level L4.

These covers both reduce the number of files actually transferred and act as a skip-list index over a ref’s version history, letting a fetch quickly determine which packfiles it needs.

The complexity OpenAI gives is:

• Synchronous metadata reads/writes on push: O(1).
• Metadata lookup on fetch: O(log Δ), where Δ is the shortest ref-version distance between the version the client has and the target version.

Interestingly, Pando doesn’t simply delete all lower-level packfiles after merging. Instead, it keeps data at different levels and picks the appropriate version range based on what the client actually needs.

The whole read path also uses Git’s packfile-uri capability, handing data distribution off to object storage and regional caches.

OpenAI maintains a dedicated Express service for this, routing packfile requests via consistent hashing, with a regional cache hit rate above 99%.

In the end, the server is mainly responsible for validation, version negotiation, and packfile selection, while the caches carry most of the data transfer.

How Does It Differ from Anthropic’s Scion?

Let’s go back to Scion, which I covered earlier.

Anthropic and OpenAI both ran into the high-concurrency development problems caused by agents, and both use techniques such as immutable data, content addressing, distributed storage, and multi-layer caching. But their attitudes toward Git itself are clearly different.

Anthropic: Rethinking Whether a Full Local Git Is Still Needed

One of Scion’s basic assumptions is that the vast majority of clients are always-online agents and CI jobs.

So the full local repository Git provides for offline development actually becomes a burden for their workload.

Scion moves operations like commit, merge, and rebase to the server, and clients maintain only a limited object cache and working files.

Some CI jobs only need to know the diff between two versions, which can be queried entirely through an API without actually checking out the repository.

Scion also drops Git’s packfile mechanism altogether, using on-demand object transfer based on trees and blobs instead.

Anthropic reports that Scion reduced CPU and memory infrastructure usage by about 200x compared with the previous Git mirror architecture, and brought checkouts for CI and research jobs down from minutes to seconds.

OpenAI: Keep Git, Change the Server Implementation

Pando takes a different approach.

OpenAI believes Git’s client protocol and development workflows still have value, and that the problem lies more in how traditional Git servers handle highly concurrent requests.

They keep existing workflows such as commit, branch, push, and fetch, and concentrate most of the optimization on the server:

• Coordinate different refs independently.
• Write packfiles directly to object storage.
• Reuse packfiles as much as possible.
• Distribute data through regional caches.
• Optimize access to historical data via background compaction.

This means existing development tools and workflows keep working, and migration costs stay relatively manageable.

Of course, Pando doesn’t work entirely without client cooperation. For the best performance, OpenAI maintains its own Git distribution, with improvements to capabilities such as packfile-uri, parallel downloads, and explicit haves.

Some of these changes have already been contributed upstream to Git.

Is One Approach Better?

They’re hard to compare directly.

Scion’s and Pando’s performance numbers come from different systems, workloads, and benchmarks. You can’t simply use Scion’s 200x infrastructure reduction and Pando’s 80% drop in push latency to decide which approach is better.

Scion prioritizes how agents and CI can fetch and operate on source code at lower cost, so it concentrates many capabilities on the server and even lets clients skip building a full working copy.

Pando prioritizes improving write concurrency and data distribution throughput while preserving the Git ecosystem.

The two are solving related problems with different emphases.

I think in the short term, Pando’s approach is easier for existing Git hosting providers to borrow from, since it’s relatively non-intrusive to existing toolchains, and some of its optimizations are already making their way into the open-source Git ecosystem.

Scion offers a more exploratory direction: if the primary users become always-online agents, does a version control system still need to maintain Git’s current symmetric client-server model?

How Will Software Engineering Change in the Agent Era?

Looking at these two posts together is more interesting than discussing either implementation on its own.

1. Agents Are Changing Software Engineering Workloads

Traditional engineering infrastructure is usually designed around the working rhythm of human engineers.

An engineer might commit only a few times a day, and code review and CI are usually fast enough to keep up.

Agents work differently.

A single engineer can launch a dozen or more agents at once, each continuously writing code, committing, running tests, fixing issues, and then starting the next round.

The result is a rapid increase in the frequency of commits, branch creation, CI scheduling, and builds.

Anthropic’s numbers make this concrete: in May 2026 it merged about 2,500 code changes per day on average; by September that had exceeded 30,000.

This means engineering infrastructure has to start dealing with high-concurrency systems problems, such as throughput, hotspot contention, cache hit rates, distributed consistency, and resource isolation.

In the past, these problems came up mostly in databases, message queues, and distributed storage. Now even version control systems need similar techniques.

2. Re-examining Some Default Design Constraints

Scion and Pando both did something worth noting: they re-examined constraints that were long taken for granted.

Scion found that for always-online agents, there’s no need to require clients to always hold the full repository history.

Pando found that updates to different branches don’t need to maintain a global time order across the whole repository.

These trade-offs can deliver very significant performance gains.

But that doesn’t mean Git’s original design was flawed. Git serves a huge variety of development scenarios, including offline development, open-source collaboration, distributed teams, and personal projects.

Scion and Pando target highly centralized, ultra-large monorepos, further optimizing the workloads that matter most there.

When the usage scenario changes, design constraints that once made sense can become new scaling bottlenecks.

3. Code Gets Written Faster, but Does Delivery Get Faster Too?

I think this is a question more worth pondering than Git performance.

In the past, a major constraint on software development was that writing code required a lot of human effort. AI agents are significantly lowering that cost.

But faster code production doesn’t automatically speed up software delivery by the same proportion.

Code still has to go through testing, review, integration, deployment, and runtime validation.

In its Scion post, Anthropic mentions that traditional merge queues relying on a global lock struggle to keep up with agent scale. While tests are still running, hundreds or even thousands of changes may already have been merged.

So they began placing more emphasis on automated testing after merge and before deployment, and letting Claude handle conflicts caused by large numbers of concurrent changes.

OpenAI’s Pando likewise improves how efficiently a change goes from push to being available to other systems.

The two companies are tackling different bottlenecks in the software delivery pipeline.

But I believe the more code gets produced, the more important it becomes to verify whether each change is correct, whether it meets business constraints, and whether it can ship safely.

The core metrics of software engineering may need to shift from commit counts and lines of code toward the throughput of effectively verified changes.

If an agent can commit a hundred times a day but only a handful of those changes reliably make it into production, then faster source control has solved only part of the problem.

4. Agents Are Also Helping Rebuild Their Own Infrastructure

The two companies share one more thing: these new systems were themselves built with heavy involvement from AI agents.

OpenAI says Pando took only 10 weeks from project kickoff to production deployment. The core architecture was designed by one engineer, multiple groups of Codex agents worked on the implementation, and a small number of engineers handled deployment.

They also used deterministic simulation testing, Git compatibility tests, and Lean and TLA+ formal models written by GPT-6 Astra to verify concurrency and consistency issues in the system.

At Anthropic, a team of about seven people built and migrated multiple systems, including Scion and Antique, within five months, relying heavily on Claude for implementation and optimization.

This may mean the way infrastructure engineering is organized is changing, too.

Engineers still need to understand distributed systems, data structures, consistency models, and business constraints, but more of their work will shift toward architecture design, defining correctness conditions, building verification systems, and judging whether agent-produced implementations meet expectations.

Moreover, agents producing code faster also raises the risk of system complexity spiraling out of control. The lower-level the infrastructure, the more it needs rigorous testing and verification.

Final Thoughts

The arrival of Pando and Scion points to at least one trend: AI agents have begun to have a real impact on software engineering infrastructure.

Anthropic chose to redesign version control, while OpenAI chose to keep the Git ecosystem and rebuild the server side. Both approaches have achieved good results.

That said, for most everyday development teams, there’s no need to replace Git right now. Both companies face very particular large-scale monorepo workloads, and their performance gains depend on specific business scale and infrastructure conditions.

What’s truly worth learning from is how they rethought existing architectural constraints, and how they used immutable data, caching, concurrency control, and on-demand computation to reduce system costs.

From Scion to Pando, one shift is fairly clear: as AI agents drastically lower the cost of producing code, the bottlenecks in software engineering are moving to source control, builds, testing, review, and delivery.

We’ll likely see more infrastructure designed specifically for agent workloads.

And Git is just one of the first links to feel the impact.

References

1. Scaling Git at OpenAI, OpenAI, 2026-11-02
2. Redesigning source control at Anthropic, Anthropic, 2026-10-13
3. Anthropic’s In-House Version Control: Scion, Leafw’s Blog, 2026-10-14
4. OpenAI’s public Git repository