Pando: OpenAI Replaced the Git Backend Under Its Monorepo

OpenAI's Pando backend now powers all monorepo development: median push latency cut by nearly 5x on OpenAI's own workload, nearly a petabyte of Git data delivered per day, and a deliberate trade of repository-wide consistency for write scalability.

One engineer can now have three changes waiting on CI at the same time, and every push kicks off several jobs that fetch the same commit. Multiply that across every branch, every merge, every clone, and the Git backend stops being plumbing and becomes the thing standing between an agent’s first commit and the merge queue.

OpenAI published an engineering account of Pando earlier this week: a new backend for Git repositories that now powers all development in its monorepo, built without interrupting engineering work or changing how the team uses Git.

The symptoms of the old system

Before Pando, OpenAI says the systems supporting the monorepo were struggling. Slow fetches and pushes. Failed merges. Reliability at times falling below 90%.

Those are OpenAI’s own words about its own infrastructure, and they describe a specific failure mode: not a bug, not an outage, but a backend that got slower and less reliable as the number of concurrent actors on the repository went up.

What Pando is

Pando is a new Git-repository backend. It is not a fork of Git that engineers have to adopt differently — OpenAI says it retains compatibility with the Git protocol and the Git client, so the team swapped the backend without changing how it works. That compatibility was a design constraint, not an accident, and it is why existing tooling and agents could move onto it unchanged.

The headline numbers, all OpenAI’s own:

Figure What OpenAI reports
Median push latency Cut by nearly 5x versus the internal system it replaced, on OpenAI’s workload
Git data delivered Nearly a petabyte per day
Predecessor reliability Below 90% at times
Push metadata cost O(1) metadata reads and writes
Fetch metadata cost O(log Δ) metadata reads
Comparison simulation 1,000 clients, each on a distinct branch
Time to production 10 weeks from kick-off, built with Codex

The 5x is a median push-latency improvement measured against OpenAI’s previous internal system on OpenAI’s own workload. It is not a Git-versus-Pando benchmark, and it does not mean Git is five times slower than Pando. The petabyte is delivered volume per day — the amount of Git data moving through the system — not the size of OpenAI’s repository.

How Pando scales writes and reads

Three design choices do the work.

Branch-independent ref coordination. Pando coordinates updates to each branch independently, so pushes to unrelated branches proceed in parallel instead of contending with each other. One engineer’s push to feature/login no longer waits on someone else’s push to fix/flake.

Causal consistency, with the cost stated plainly. Updates to an individual ref remain serializable. But a client reading several branches cannot assume those reads describe a single point in time. Pando does not give you a point-in-time snapshot across all refs, and OpenAI frames this as a deliberate design choice rather than a gap. The system trades repository-wide consistency for write scalability and read throughput. Say it plainly: consistency-everything is what you give up.

Packfile reuse across fetches. Pando reuses packfiles across fetches instead of generating an individual packfile per client, which is what lets read throughput scale from cache rather than from per-client CPU and disk.

The metadata costs follow from that. A push requires O(1) metadata reads and writes. A fetch requires O(log Δ) metadata reads, where Δ is the shortest distance in ref versions between what the client has and what it wants. Different operations, different numbers — the push path stays flat no matter how many branches are in flight, and the fetch path scales with how far behind the client is.

What the comparison actually showed

OpenAI’s comparison was a simulation, and it should be read as one. It configured 1,000 clients, each selecting a distinct branch and repeatedly pushing unique commits, measuring wall-clock duration and push-to-fetch latency against three-phase-commit and write-ahead-log designs, modelling commodity-to-premium hardware and blob storage.

In that simulation and in real-world testing on the monorepo, OpenAI says Pando supports many thousands of clients pushing concurrently without impacting performance under load.

That is a vendor’s own simulation of a vendor’s own architecture. Nobody outside OpenAI can reproduce it, and it is not a published benchmark. It is still the most concrete evidence available for the design, and it does not tell you what happens at ten times the scale or on a workload with a different branch-to-push ratio.

The governance story

OpenAI puts it bluntly: “We built Pando with Codex, moving from kick-off to production, in just 10 weeks. The core of Pando was designed by a single engineer, implemented by teams of agents, and deployed by a handful of engineers.”

Read that carefully, because the paraphrase is always stronger than the original. One engineer did not build Pando. The core was designed by a single engineer, implemented by teams of agents, and deployed by a handful of engineers. The sentence is about how the work was divided, not how much of it a person did alone.

What the claim does support: the design is the scarce step, agent teams can carry a real implementation against it, and a small group of humans can own deployment of a system that ends up running everything. What it does not support: that agent-built infrastructure is cheap to maintain, that 10 weeks included the hardening a new backend needs, or that the result generalizes beyond one company’s workload. OpenAI is also the vendor here, and the quote is a case study of its own success.

The improvements go upstream

OpenAI develops against its own copy of Git at github.com/openai/git, and says the improvements it makes there are intended for upstream Git. The blast radius is the whole ecosystem, not just OpenAI. Pando itself is a backend rather than a fork, so the wider Git community gets the upstream changes without running Pando — the strongest argument that this is ecosystem infrastructure and not a vendor lock-in.

The takeaway

The lesson is not “Git is slow.” Git is a fifteen-year-old protocol that survived every scaling story written about it. The lesson is that consistent-everything costs you horizontal writes, and once your number of concurrent writers scales with the number of agents on your team, that trade stops being optional and becomes the design.

If you are running a platform where write concurrency grows with headcount or with agent count, look at where you are paying for global consistency on every ref update. That is the bill Pando stopped paying — and it is a bill most teams have not noticed they are paying yet.

Sources