OpenAI's In-House Pando: Cutting Push Latency by 80%

OpenAI has built its own Git backend, Pando, for its massive monorepo. According to the company, it cuts median push latency by nearly 80% and handles close to a petabyte of Git data transfer every day. The significance of this news goes beyond a single performance optimization—it exposes a frequently overlooked fact: once a codebase crosses a certain scale threshold, the architectural assumptions of standard Git start to break down.

When a Monorepo Hits Git's Ceiling

OpenAI's code lives in one enormous monorepo. This organizational choice buys the convenience of cross-project dependencies and unified builds, but the cost falls on the version control layer. When a traditional Git server handles massive numbers of branches and frequent fetches, a great deal of work gets recomputed—every fetch often requires regenerating or repacking objects, and operations across branches are hard to isolate from one another.

Pando's starting point is clear: stop treating Git as a black box that must be adapted wholesale, and instead rewrite the backend so that storage and transfer logic fits the actual access patterns of a monorepo. This aligns with the thinking behind other hyperscale code hosting platforms, but OpenAI chose to build everything in-house rather than modify an existing solution.

What is a packfile: When Git transfers and stores objects, it packs large numbers of loose objects into one or more packfiles and builds an index (.idx file) for the objects inside. Packing involves object traversal, delta compression, and reorganization—it is a compute-intensive operation. The larger the repository and the more objects it holds, the higher the cost of a single repack, which is one of the main reasons fetches are slow in large repositories. Reusing existing packfiles essentially means skipping the redundant packing computation and handing an already-validated packing result directly to the client.

What is fetch: Fetch is the operation by which Git pulls objects and reference updates from a remote. Unlike pull, it does not automatically merge into the local branch. In a monorepo, fetches are frequent and involve many objects, and the server must decide each time which objects to send and how to pack them—making it a core battleground for latency optimization.

Three Key Design Choices

The official description of Pando centers on three capabilities, each targeting a specific pain point of standard Git in very large repositories.

Independent Branch Processing

Pando processes each branch independently of the others. In traditional implementations, once the number of branches balloons, the server's reference management and object traversal costs rise nonlinearly; independent processing means that reads and writes on a single branch are no longer dragged down by the scale of other branches. For a monorepo with tens of thousands of active branches, this is key to controlling latency variance.

The cost of reference and object traversal: Git references (refs) are essentially pointers to commit objects, and branches are one kind of reference. When handling a request, the server must resolve references, traverse commit history, and determine which objects the client already has (through negotiation). When active branches reach the tens of thousands, the overhead of reference management and reachability analysis grows with the branch count, and operations on different branches can easily block one another. The point of independent branch processing is to break this global coupling so that the processing path for a single-branch request no longer degrades linearly with the repository's total branch count.

Reusing Packfiles Across Fetches

Pando reuses stored packfiles across multiple fetches. The Git protocol has always supported packed transfers, but in the standard path the server often has to reorganize the object set for every request. Reusing existing packing results removes redundant packing overhead from the hot path and directly reduces wait times for fetches in large repositories.

Gains in Both Latency and Throughput

These designs ultimately show up in two metrics: a nearly 80% drop in median push latency, and close to a petabyte of Git data delivered daily. The former reflects what developers feel in their day-to-day operations; the latter validates the backend's stability under heavy load. Both holding true at once shows the optimization did not come at the expense of throughput.

Why This Matters

OpenAI has not released Pando as a product; it is more of an infrastructure-level proof of concept. But the signal it sends has broader relevance.

First, version control for very large codebases is shifting from "configuration tuning" to "backend rewrites." Once a repository reaches a certain scale, parameter tuning and caching can no longer solve the problem, and redesigning the storage and transfer paths becomes the only way forward.

Second, AI companies are deepening their investment in development infrastructure. Beyond training and inference, the efficiency of the code collaboration pipeline also affects iteration speed, and Pando is one of these invisible but critical engineering investments.

Third, Git compatibility is preserved. As a Git-compatible backend, Pando means existing clients and workflows need no changes. This "swap the backend, keep the frontend unchanged" path offers a reference point for teams similarly struggling with monorepos.

Version control trade-offs of a monorepo: A monorepo puts multiple projects into a single codebase, bringing the convenience of atomic commits, unified dependencies, and cross-project refactoring—but it also stresses the version control layer: large clone sizes, numerous branches, and CI that must do incremental builds by path. Industry responses fall roughly into two categories—one is a virtual filesystem (such as VFS for Git and parts of Sapling's approach), materializing files on demand; the other is rewriting server-side transfer and storage, which is where Pando fits. Understanding this divide helps in judging the scale range each approach suits.

Limitations and Open Questions

Public information is limited so far: whether Pando is open source, whether it works for repositories outside OpenAI's scale, and the specific object distribution behind the near-petabyte daily traffic are all undisclosed. The nearly 80% latency reduction is a median measured under OpenAI's own workload, and whether other teams can reproduce it depends on how similar their access patterns are. For most small and mid-sized teams, standard Git remains the more economical choice; Pando's value lies in marking the feasibility boundary of the self-built backend path.

One-line Summary

OpenAI's in-house Git-compatible backend Pando cuts median push latency in its monorepo by nearly 80%.

Paragraph Summary

OpenAI has built a Git-compatible backend called Pando for its hyperscale monorepo, which the company says cuts median push latency by nearly 80% while handling close to a petabyte of Git data transfer daily. The article notes that the real significance of this optimization is that it reveals how standard Git's architectural assumptions fail once a repository crosses a scale threshold: traditional servers repack objects on every fetch, and as branch counts balloon, reference management and object traversal costs rise nonlinearly. Through designs such as independent branch processing and reusing existing packfiles across fetches, Pando removes redundant computation from the hot path while balancing latency and throughput. The article argues this marks a shift in version control for very large codebases from configuration tuning to backend rewrites, and that the path of staying Git-compatible with no client-side changes offers a reference for similar teams—though whether Pando will be open sourced and whether it can fit repositories of other scales remain to be seen.