Summary
OpenAI says Pando, its new Git-compatible repository backend, now powers all development in its monorepo. The company reports that it cut median push latency by nearly 5x and serves nearly a petabyte of Git data per day.
OpenAI says its new Git backend, Pando, now powers all development in the company's monorepo. It is designed to handle many pushes to different branches at once while serving repository data to large numbers of readers. OpenAI reports that Pando cut median push latency by nearly 5x and now delivers nearly a petabyte of Git data per day.
The system keeps the Git protocol and client, so engineers and agents can continue using familiar workflows. Its redesign is behind the repository service, not a replacement for Git itself.
Why OpenAI rebuilt its Git backend
OpenAI attributes the increased load to Codex-enabled development work happening in parallel: more branches and pushes, followed by more merges, fetches and clones from development environments, research jobs and continuous-integration systems. The company says its previous systems struggled to keep pace, with slow operations and failed merges; reliability at times fell below 90%.
Git stores repository content as objects, including file contents, directory structures and commits. Branches are references, or refs, pointing to commits. A push sends objects to the server and asks it to move one or more refs. Systems that coordinate every ref update through a single repository-wide ordering point can make pushes to unrelated branches wait on one another.
Pando's design instead coordinates updates to each branch independently. That allows pushes to unrelated branches to proceed in parallel, while preserving serializable updates to an individual ref: competing pushes to the same branch still need to be resolved against its current version.
Pando's design and its consistency trade-off
When a client pushes, Pando stores the incoming packfile—a compressed collection of Git objects—as an immutable blob. It records the new branch tip, the packfile that supplied it and the earlier ref versions on which that packfile depends in a metadata store. Both the blob and metadata stores are designed to scale horizontally.
Pando also reuses packfiles across fetches rather than generating a unique one for every client. A client may receive some objects it already has, but the server can reuse the same data for many readers with less computation. OpenAI says this approach helps it serve reads at high throughput.
The trade-off is that Pando does not give clients a single point-in-time view of every branch in the repository. Someone fetching several branches may see them at different moments, even though each individual branch has a consistent history. OpenAI describes this as causal consistency: a reader fetching a ref receives the history that led to the version of that ref being read.
Together, per-branch coordination and shared packfiles are intended to address the two demands OpenAI identifies: concurrent writes and high-volume reads. The reported production figures indicate the system is already in use across the company's monorepo, while the consistency model is a deliberate part of how it scales.