OpenAI rebuilt its Git server because Codex was choking it: how Pando works

OpenAI published on November 2, 2026 how it rebuilt the Git server for its monorepo: a new backend called Pando, compatible with the Git protocol and client, which now handles all development in that repository. The reason is Codex. Agents multiplied branches, pushes, and fetches until the previous system couldn't keep up: according to OpenAI, there were moments when its reliability dropped below 90%. With Pando, median push latency dropped almost 80% (nearly 5x) and the service delivers about a petabyte of Git data per day. For anyone running large repositories, CI, or fleets of agents that git push nonstop, this is the first serious report on how Git breaks at agent scale and what had to be sacrificed to fix it.

The problem: Codex multiplied the traffic

OpenAI says that, with Codex, a single engineer has several changes ready for CI at the same time, and each push can trigger several jobs that download the same commit. More branches, more merges, more clones from development environments, research jobs, and CI. The effect compounds.

The chart it published makes this clear. Commits landing on master grew 264% between the first quarter of 2024 and the last of 2025, and 1,378% by the third quarter of 2026. For the fourth quarter of 2026 OpenAI estimates 2,442%, but note: that last number is its own projection, not measured data, even though some headlines cite it as if it had already happened.

Bar chart showing quarterly commit growth in OpenAI's monorepo, from 0% in the first quarter of 2024 to +1,378% in the third quarter of 2026, and an estimate of +2,442% for the fourth

Since late 2025, according to the post, pushes and fetches were slow and merges failed. The question they asked themselves was whether they had hit a limit of Git or a limit of how they were serving their monorepo. Their conclusion was that they could keep the usual Git workflow and rebuild the backend.

The two classic approaches and why they weren't enough

OpenAI modeled the two common ways of scaling a Git server:

Approach	How it coordinates	Where it gets stuck
Three-phase commit (3PC)	Full replicas of the repo; a majority must accept each ref update	Each push waits for several rounds between replicas and each one's disk; writes become slow under load
Write-ahead log (WAL) on blob storage	A shared manifest updated with compare-and-swap	Even pushes to completely unrelated branches compete for the same manifest; replicas fall behind reading and indexing packs and reads become slow

In both cases the bottleneck is the same: the system lines up all of the repository's writes in a single queue.

Pando's two trade-offs

Pando gives up two things that almost every Git server takes for granted.

1. Whole-repository consistency at a single instant. Pando guarantees the ordering of updates for each ref separately, but not a simultaneous snapshot of all branches. OpenAI calls it causal consistency: two clients only collide if they push to the same ref at the same time. The cost is that a client reading several branches may see them at different moments. Their argument is that, in practice, neither people nor agents depend on global ordering, only on the ordering of each branch.

2. A packfile tailored to each client. A normal server calculates which objects are missing for whoever is fetching and builds a new pack, which costs CPU and disk and can hardly be cached. Pando stores the packfile that arrived in each push as an immutable blob and reuses it to serve everyone who asks for it afterward. Sometimes the client downloads objects it already had, but the server computes almost nothing.

For those packs to be reusable, Pando doesn't show the client all its branches during a push: by default it only advertises a single trunk branch. That way the pack depends only on that base and anyone who has it can use it. OpenAI admits that, if someone pushes many times to the same branch or stacks branches, each push resends everything that's outside the trunk. In its monorepo, the median of those packs came out under 20 KiB and the 99th percentile under 3 MiB.

How it works under the hood

Pando diagram: the writing client sends a packfile, Pando stores it as is in blob storage and records the ref version in the metadata store; the reading client sends haves and wants, receives packfile URIs and downloads them from the Express regional cache

Push. Pando validates the packfile while streaming it to blob storage, without unpacking it into a local repository. Then, in a transaction, it records a ref version (the new tip, the pack that brought it, and its dependencies) and moves the branch pointer with an atomic compare-and-swap-style operation. OpenAI says this costs a constant number of metadata reads and writes, regardless of the push size.
Fetch. With the client's haves and wants, Pando looks up the ref versions it needs and responds with links to already stored packfiles, using packfile-uri, a little-known feature of the Git protocol. The client downloads them from Express, a regional cache; OpenAI reports cache hit rates above 99%.
Compaction. Since downloading one pack per push would be impractical (tens of thousands per day), some workers group the small packs into tiers, LSM-tree style. Today the monorepo uses up to level L4. Those levels also work as an index for choosing packs in logarithmic time, and no level is deleted.

According to OpenAI, with standard virtual machines from a cloud provider, clones and fetches saturate 10 Gbps links. Pando served more than 57 TB of packs in one hour, more than 99% of it from local disk cache.

Built with Codex in 10 weeks

The fact that will circulate the most: Pando went from kickoff to production in 10 weeks. OpenAI says the core was designed by a single engineer, implemented by teams of agents, and deployed by a few engineers. It's written in Rust, with no legacy dependencies, with a suite of conformance tests against standard Git behavior and deterministic simulation tests. They also say they used agents to write formal specifications in Lean and TLA+ with which they found and fixed bugs. It has been handling production traffic since April 2026.

The migration was done without shutting anything down: first Pando worked as a read and write proxy in front of the previous system, and clients moved over in phases with an internal wrapper around the Git CLI. OpenAI even ships its own build of Git to its developers' machines and inside the ChatGPT desktop app.

What actually reaches you

Pando is not a product you can install. OpenAI only says it is exploring ways to share the technology with its users, with no dates. What is public:

Its Git fork on GitHub (openai/git), with improvements like downloading and indexing packs in parallel and explicit haves, which allow using --force-with-lease and building the pack against the trunk only.
Patches to upstream Git: fixes for concurrent downloads, cleanup after interrupted transfers, download resumption, and traces for packfile-uri. Its public patch tracker lists 50 for upstream; several are already in Git and others are still under review.

My take

What's interesting isn't that OpenAI has a huge monorepo, but how it solved it: it kept Git as the interface and changed the server's guarantees. It's a bet that the Git client, which every human and every agent already uses, is worth more than global consistency.

For a small team this doesn't change your Monday: a GitLab or a Gitea on a VPS holds up just fine. But the trend does matter. If you put agents to work opening branches, running CI, and pushing changes in parallel, your Git server stops being boring infrastructure and becomes a bottleneck. Before buying more disk, it's worth measuring how many fetches each push triggers and how many times CI clones the same thing.

A note on rigor: some coverage says merge reliability reached 99.99%. OpenAI's post doesn't give that figure; it only says it improved. This piece comes from OpenAI's technical article and its public repositories; I haven't tested it.