OpenAI rebuilt the Git backend behind its monorepo to keep up with Codex agents

OpenAI has published a detailed account of how it replaced the system serving its main code repository. In Scaling Git at OpenAI, dated November 2, Aaron Friel, Taylor Blau and Ted Nyman describe Pando, a new backend for Git repositories that "now powers all development in OpenAI's monorepo". The reason they give is blunt: the volume of parallel work that Codex makes possible had outgrown the previous setup.

The post reached the Hacker News front page within hours. It matters beyond OpenAI because it is one of the first detailed, first-hand descriptions of what coding agents do to source control once they are used at scale.

What broke

According to OpenAI, Codex lets each engineer run far more work in parallel, which means more branches, more pushes, more merges and more fetches from development environments, research jobs and CI. "One engineer now has several changes ready for CI at once, and each push can set several jobs fetching the same commit," the authors write.

Starting around the end of 2025, the systems behind the monorepo "were struggling to keep up", with slow fetches and pushes, failed merges, and "reliability at times falling below 90%", the post says. The New Stack reports that, according to OpenAI, quarterly commits to the monorepo will have grown by more than 2,400% by the end of this year compared with the first quarter of 2024.

The team's question was whether it had hit a limit of Git itself or of the way it served the repository. Its answer was the second, so it kept the Git protocol and client and rebuilt the server side.

How Pando works

OpenAI says Pando drops two things most Git servers treat as requirements.

No repository-wide snapshot. Conventional designs order all reference updates across the whole repository, so a push to one branch can wait on a push to an unrelated one. Pando coordinates each branch independently. The only contended key is the branch pointer, protected by an atomic compare-and-swap style operation. OpenAI calls the result causal consistency: updates to a single branch are serialized, but a client reading several branches may see them at slightly different points in time. "In practice, users and agents are agnostic to the global ordering of ref updates," the authors argue.

No custom packfile per client. A normal Git server computes, for each fetch, the objects the client lacks and compresses a fresh packfile. Pando instead stores every pushed packfile as an immutable blob, records each new branch tip and its dependencies in a metadata store, and on fetch selects stored packs that cover what the client needs. It hands back download links through packfile-uri, an existing but rarely used Git protocol feature, and a cache service called Express serves the bytes from regional caches with hit rates above 99%.

To make packs reusable, Pando advertises only the trunk branch when a client pushes a new feature branch, rather than listing every ref. OpenAI notes that with millions of branches the full ref advertisement alone can exceed 100 MiB. The tradeoff is that repeat pushes to a branch resend everything not on trunk; in OpenAI's monorepo the median pack produced this way was under 20 KiB and the 99th percentile under 3 MiB.

Because thousands of small packs per day would slow clients down, background workers merge them into larger "covers", in a way the post compares to compaction in log-structured merge-trees. The monorepo currently uses up to four levels of covers, which also let Pando plan a fetch in logarithmic time relative to how far behind a client is.

The numbers OpenAI reports

All figures below come from OpenAI's post and have not been independently measured:

• median push latency cut by nearly 5x (the post also phrases it as nearly 80% lower);
• close to a petabyte of Git data delivered per day, "with just a handful of CPU cores";
• more than 57 terabytes of packs served in a single hour, over 99% of it from local disk cache;
• clones and fetches saturating 10 Gbps links on standard cloud virtual machines.

The interactive simulation in the post comparing Pando with three-phase commit and write-ahead-log designs is labelled by OpenAI as "synthetic teaching models, not production benchmarks".

Built with agents, in 10 weeks

OpenAI says it went from kickoff to production in 10 weeks, with the core "designed by a single engineer, implemented by teams of agents, and deployed by a handful of engineers". Pando is written in Rust and has served production traffic since April. The team wrote a Git conformance test suite so agents could check their changes against standard Git behavior, and used deterministic simulation testing to find race conditions. It also says agents running GPT-6 Astra wrote Lean and TLA+ specifications to formalize a "theory of Pando", which were used to find bugs and prove properties of the system.

Migration was gradual. Pando first ran as a read- and write-through proxy in front of the old system, and OpenAI now ships its own Git build to developer machines and inside the ChatGPT desktop app. Developers could ask Codex to migrate their own environments using dedicated skills.

What goes back to Git, and what does not

OpenAI says it has sent client fixes back to the Git project, covering concurrent packfile-uri downloads, cleanup after interrupted transfers and new tracing, and that several are already in upstream Git. Ted Nyman's patch series on concurrent downloads is public on the Git mailing list. Other changes, such as parallel pack indexing and "explicit haves", live for now in OpenAI's public Git fork, tracked on a patch status page that, when we checked, listed 50 patches for upstream and 92 commits carried on top of upstream Git.

Pando itself is not open source. OpenAI only says it is "exploring ways to share the technology that makes Pando possible with our users". The New Stack notes that Anthropic has also built its own source-control system, Scion, which it has no plans to release, and that startups such as Entire and Cursor's Origin project are working on the same problem.

Why it matters for teams running coding agents

Few teams have OpenAI's volume, but the failure pattern it describes scales down. When each developer runs several agents, the bottleneck moves from writing code to everything around it: pushes landing at the same time, CI jobs cloning the same commit, branch counts growing fast. OpenAI's diagnosis is that the Git client and protocol held up and the server design did not.

Some practical takeaways from the post:

• Watch contention, not just storage. Systems that order every write across a repository make unrelated agent branches wait on each other.
• Reads multiply faster than writes. One push can trigger several fetches; caching identical responses mattered more for OpenAI than shrinking each pack.
• Staying on Git paid off. Keeping the protocol meant no retraining for engineers or agents, and every client fix can benefit the wider ecosystem.

The open question is whether GitHub and other hosts will adopt similar tradeoffs, such as relaxing repository-wide consistency, before agent-heavy teams start building their own backends.