OpenAI builds Pando, a Git-compatible backend for Codex-scale development

OpenAI says Pando, a new backend for Git repositories, now powers all development in its monorepo. In production, the company says, it cut median push latency by nearly 5x and now delivers nearly a petabyte of Git data per day. Engineers Aaron Friel, Taylor Blau and Ted Nyman wrote the account, dated November 2, 2026.

The company's stated reason is the load Codex created. According to the post, the coding agent let engineers do far more work in parallel. That means more branches and pushes, more merges, and more fetches and clones from development environments, research jobs and CI. The demands compound. One engineer may have several changes ready for CI at once, and each push can set off several jobs fetching the same commit. Starting around the end of last year, OpenAI says, its monorepo systems struggled with slow fetches and pushes, failed merges, and reliability at times below 90%. The engineers asked whether they had hit a limit of Git itself, or of the way they served the monorepo.

OpenAI chose to keep Git's protocol and client, so engineers and agents can adopt Pando within their existing workflows. The post argues this matters because developers have spent more than two decades adapting their tools around Git, and because improvements to the client can be useful outside the company. Pando's goals, as the post states them, are horizontally scalable writes, optimized for concurrent pushes to many branches, and read throughput high enough that clients can fully saturate their available network bandwidth.

Understanding the design requires knowing how Git stores history. A repository is a graph of immutable objects: blobs for file contents, trees for directories, and commits and tags, each identified by a hash of its type and contents. Branches and tags are references that point to commits. A fetch works by having the client say which commits it wants and which it already has. The server then sends the missing objects as a packfile, Git's format for compressing multiple objects together. A push runs the other way and depends on what the server already holds, so the pack alone cannot rebuild the new history. Replication therefore has to keep objects and references in step across servers, and competing updates to the same branch have to be ordered.

The post compares Pando with two conventional designs OpenAI says it modeled. The first uses three-phase commit. Each server keeps a complete copy of the repository, a majority of replicas must accept each ref update, and the coordinator runs several rounds of messages per push. Because replicas stay complete so that any of them can serve a consistent view, references are updated one at a time. Disk speed and network latency sit on the push path. The second uses a shared write-ahead log: a manifest in blob storage that orders all updates through compare-and-swap. Pushes to unrelated branches still have to update that one manifest, and each replica must read and index new packs before serving them. The post says adding blob store capacity alone does not remove that bottleneck.

Pando's answer is to relax two assumptions most Git systems keep. It drops repository-wide consistency, so there is no single point-in-time snapshot of all refs. It also stops giving each client a unique packfile. Each push's packfile is stored as an immutable blob. Each branch move is recorded as a ref version in a metadata store that notes the pack and any earlier versions it depends on. A fetch replays the relevant ref versions to rebuild the state that produced the requested ref. The result is serializability for updates to a single ref, while clients conflict only when they push to the same ref at the same moment. The cost falls on readers: a client reading several branches can see them at different points in time. The post's example has one client see foo at version 1 and bar at version 2 while another sees the reverse. It argues that users and agents depend on the order of updates to one reference rather than a global order.

The read side follows the same logic. Without reuse, a server may need to generate a different packfile for each client, which costs CPU and disk I/O. Pando instead reuses stored packfiles, so the server can send the same bytes to many clients. On push, Pando validates the incoming pack while streaming it to blob storage, without unpacking it into a local repository. On fetch, it selects the stored packs a reader needs. The post says these servers mainly negotiate and select packs, which is why they can run on commodity hardware. Scaling then means adding Pando servers together with the metadata and blob stores.

The comparison is a simulation, and the post is explicit about what that means: it describes the models as synthetic teaching models, not production benchmarks. In it, 1,000 clients each select a distinct branch and repeatedly push unique commits. The simulation measures total duration and push-to-fetch latency across hardware from commodity to premium virtual machines and blob storage. The post says three-phase commit shows significantly greater write latency under load as its disks saturate. Write-ahead log systems show significantly greater read latency as servers struggle to keep up with the journal. It also says that in real-world testing on its monorepo and in the simulation, Pando supports many thousands of clients pushing concurrently without impacting performance under load.

OpenAI also points to its work on upstream Git. Its public openai/git repository, forked from git/git, lists 50 patches prepared for upstream and 92 commits carried on top of upstream in its build. The repository tracks the upstream status of each topic. Some are in upstream's seen branch and others are not yet merged. It lists patches on repacking, multi-pack indexes, fetch negotiation and pack downloads. The Pando post says the company will keep contributing its Git improvements to the project to support agent-scale work.