OpenAI builds Pando, a new Git backend that cuts push latency 5x for agent-scale development

The Codex problem

Over the past year, the size and demands on OpenAI's monorepo increased at a staggering pace. Codex, OpenAI's AI coding agent, enabled engineers to do far more work in parallel. That meant more branches and pushes, more merges, and more fetches and clones from development environments, research jobs, and CI.

One engineer now has several changes ready for CI at once, and each push can set several jobs fetching the same commit. Starting around the end of 2025, the systems supporting the monorepo were struggling to keep up. Slow fetches and pushes along with failed merges pushed reliability below 90 percent at times.

OpenAI faced a choice: had they reached a limit of Git itself, or of the way they served their monorepo? They concluded the answer was the latter, and set out to rebuild the backend while keeping Git's familiar client interface.

What Pando does differently

Pando makes two key design choices that distinguish it from conventional Git scaling approaches. First, it provides causal consistency rather than repository-wide consistency: updates to unrelated branches can proceed in parallel, and a reader fetching a branch gets the history needed for that revision. The tradeoff is that a reader looking at several branches can see them at different points in time.

Second, Pando reuses packfiles across fetches instead of generating an individual packfile for each client. A client may download some objects it already has, but the server can serve the same bytes to many clients with little computation.

When a client pushes to a branch, Pando stores the incoming packfile as an immutable blob in a horizontally scalable blob store. Each time the branch moves, Pando records a ref version containing the new tip, the pack that supplied it, and any earlier ref versions the pack depends on in a metadata store. Fetching a commit requires replaying a set of ref versions to the client.

The approach is reminiscent of Git's own design philosophy: Git does not manage files, it manages snapshots of a tree. Pando extends that idea to the repository level: it does not manage a single repository state, it manages a collection of ref versions that together tell the story of the repository. A client fetching main sees the same history as a client that fetched two seconds ago, but a client fetching a development branch that has not been pushed in hours sees the stale version until the next fetch.

The blob store that stores packfiles is horizontally scalable, and the metadata store that tracks ref versions uses a key-value store optimized for point lookups. Pando stores packfiles once and serves them many times, turning the read-heavy traffic pattern of a large monorepo into a cache-friendly workload.

Why not existing approaches

OpenAI evaluated two conventional approaches before building Pando. The first used three-phase commit across repository replicas, where a coordinator required multiple rounds of communication to update refs. That imposed disk performance and communication latency on the push path, and as write volume grew, replicas had to keep up with incoming packs as well as read traffic.

The second approach used a shared write-ahead log in blob storage. Writers could upload packfiles in parallel, but even pushes to unrelated branches required updating the same shared manifest. The round-trip time for a successful compare-and-swap operation limited how often the repository could publish a new manifest.

Pando avoids both bottlenecks by decoupling ref updates from one another. Clients only conflict when pushing to the same ref simultaneously, which is rare in a monorepo with hundreds of active branches.

Results and open-source contributions

In production, Pando cut median push latency by nearly 5x. It now delivers nearly a petabyte of Git data per day across OpenAI's monorepo. The system is compatible with the standard Git protocol and client, meaning both engineers and agents could adopt it without changing their workflows.

OpenAI has also been contributing improvements from its fork of Git back to the upstream community. The company described the project as investing in the Git ecosystem while building for its own needs, and said it plans to continue sharing those improvements.

Before Pando, push latency had been climbing for months as the number of concurrent pushes grew. A push that took five seconds in early 2025 could take 30 seconds or more by mid-year. After migrating to Pando, the median push dropped to under three seconds, and the 95th percentile push completed in roughly the same time as the old median.

The reliability improvements were equally significant. With the old system, merge conflicts and push timeouts caused reliability to dip below 90 percent on some days. Since migrating to Pando, reliability has stayed above 99.5 percent, OpenAI reported. The company also said it has contributed several patches back to the Git project, including improvements to the reference backend interface that make it easier to build custom backends like Pando.

How Codex changed the equation

The inflection point was not just more engineers writing code, but the way Codex writes code differently. A human engineer pushes a change every few hours. A Codex agent working on a task may push several branches in parallel, each representing a different approach to the same problem. When several engineers each run several Codex sessions, the push rate can spike to hundreds of pushes per minute.

Git was designed for the human pace: a few thousand objects per push, a few pushes per hour per developer. OpenAI's monorepo now sees pushes that contain tens of thousands of objects each, and the push volume grows roughly with the number of Codex sessions active at any time.

Pando was built to handle that pattern. By allowing pushes to proceed independently rather than serializing through a coordinator, the system can handle peak loads that would have caused the old architecture to fail. OpenAI said the system has room to scale further as Codex usage continues to grow.

What it means for agent-driven development

Pando was designed specifically for the scale of work that AI coding agents like Codex make possible. Traditional source control systems assume a human pace of development where one person pushes a few times a day. Codex and similar agents can generate dozens of parallel branches and hundreds of commits in the same period.

OpenAI's architecture suggests that source control, not just model capability, is becoming a bottleneck for AI-assisted software development. Other companies running agent-heavy workflows may face similar constraints as their monorepos grow under the load of machine-speed development.

The broader implication is that AI-assisted development is pushing infrastructure beyond what conventional tools were designed for. OpenAI is not the only company scaling a monorepo under agent-driven development, but it is the first to describe the solution publicly in detail. Other large engineering organizations running code agents at scale are likely facing similar source-control bottlenecks, and Pando represents a design pattern that could inform their own solutions.