OpenAI Details Pando, Its Git Backend: Causal Consistency Buys Branch-Level Write Scale, Median Push Latency Down Nearly 80% in Its Own Report, but the Simulation Is a Teaching Model and Pando Is Not Offered Outside OpenAI
On November 2, 2026, OpenAI engineers described Pando, a new backend that serves its monorepo without changing the Git protocol or client and now powers all development in OpenAI’s monorepo. Pando stores each push as an immutable packfile blob with a ref version, lets unrelated branches write independently, and serves reads by reusing stored packs through regional caches. OpenAI reports more reliable merges, median push latency down nearly 80% (nearly 5x in the introduction), nearly a petabyte a day, and 57 TB in one hour with over 99% from local cache. The cost is causal consistency, with no point-in-time view across branches, and a default of advertising only trunk, so repeated pushes resend data. The 1,000-client simulation is labelled a teaching model, not a production benchmark, and the post does not say Pando is available outside OpenAI.
On November 2, 2026, three OpenAI engineers, Aaron Friel, Taylor Blau and Ted Nyman, published "Scaling Git at OpenAI." The post describes Pando, a new backend for serving Git repositories that now powers all development in OpenAI's monorepo. The reason, they write, is Codex: engineers now run far more work in parallel, which means more branches, pushes, merges, fetches and clones from development environments, research jobs and continuous integration. Starting around the end of last year the old systems struggled, with slow fetches and pushes, failed merges and reliability at times below 90%.
Pando keeps the Git protocol and client, so engineers and agents did not change how they work. It has two goals: writes that scale horizontally across many branches, and reads fast enough to fill the client's network link. For writes, Pando stores each incoming packfile as an immutable blob and records a "ref version" in a metadata store. Updates to unrelated branches proceed independently, and only a push to the same ref conflicts. For reads, it reuses stored packfiles instead of building a custom pack for each client, and hands clients packfile URIs served from regional caches.
The authors compare this with two common designs they modeled: three-phase commit across full replicas, where each push needs several round trips and replica disks sit on the write path, and a shared write-ahead log in blob storage, where every push competes to update one manifest. Their interactive simulation, with 1,000 clients, shows the first slowing writes and the second slowing reads under load. The page labels the simulation as synthetic teaching models, not production benchmarks, so it explains the design and does not prove the production numbers.
The production claims are specific. Switching to Pando improved merge reliability and cut median push latency by nearly 80%, which the introduction states as nearly 5x. Pando delivers nearly a petabyte of Git data per day, has served more than 57 terabytes of packs in a single hour with over 99% of those bytes from local disk cache, and in validation saturated 10 Gbps links on standard cloud virtual machines. Express, the pack delivery service, reports cache hit rates over 99%. These are OpenAI's own figures for one monorepo, and the post gives no independent measurement or comparison against another system in production.
The post is open about the trade-offs. Pando gives causal consistency, not a point-in-time view of all refs: two clients may see two branches at different versions during a clone, while updates to a single ref stay serializable. To keep packs reusable, Pando advertises only a designated trunk branch on a push by default, so repeated pushes to one feature branch, or stacked branches, resend more data. In OpenAI's monorepo the median pack produced this way was under 20 KiB and the 99th percentile under 3 MiB. Pando also keeps packs at every compaction level, using levels up to L4 so that fetch planning takes logarithmic time instead of thousands of small downloads.
On how it was built, the authors say Pando went from kick-off to production in 10 weeks, began serving production traffic in April, and was designed at its core by one engineer, implemented by teams of agents and deployed by a handful of engineers. They wrote it in Rust, with a conformance test suite and deterministic simulation testing, and used GPT-6 Astra agents to write Lean and TLA+ models that found bugs. Rollout began with Pando as a read- and write-through proxy to the old system, so traffic moved without downtime. The post does not say Pando is available outside OpenAI.
OpenAI also contributes to Git itself. It fixed edge cases in concurrent pack downloads, cleanup after interrupted transfers and resuming completed downloads, added tracing for packfile-uri downloads, and added "explicit haves" so a pushing client can use --force-with-lease and build its pack against trunk alone. Several changes are in upstream Git and others in OpenAI's public fork. When captured, that fork on GitHub was a public fork of git/git whose codex branch was 115 commits ahead and 522 behind git/git master, with a recent merge named for packfile-uri reuse. For teams running large monorepos, the lesson is the trade: relaxed cross-branch consistency bought write scale, and it worked here because users and agents depend on the order of updates to one ref, not on a global order.
Sources
FAQ
Why does Pando relax consistency?
So unrelated branches can be written in parallel. Pando keeps updates to a single ref serializable, but across branches it offers only causal consistency, so two clients may see two branches at different versions during a clone. OpenAI judges that users and agents depend on one ref's update order, not a global order.
Are 'nearly 80%' and 'nearly 5x' two different gains?
No. The introduction says median push latency fell nearly 5x and the deployment section says nearly 80%, which describe about the same change: a fall to roughly one fifth is a cut of about 80%. Both are OpenAI's self-reported numbers for its own monorepo, not independent or cross-system production measurements.
Does the 1,000-client simulation prove production performance?
No. The page labels it synthetic teaching models, not production benchmarks, and uses it to explain how three-phase commit, a write-ahead log and Pando differ. Production claims rest on OpenAI's own figures for merge reliability, push latency, daily volume and cache hits, and the post does not say Pando is offered outside OpenAI.