OpenAI Built Its Own Git Backend Because Codex Broke the Old One

For years, the hardest part of shipping software was writing the code. At OpenAI, that’s no longer true. Its coding agent, Codex, now produces so much work that the code-storage system started to buckle, so the company replaced it.

The replacement is called Pando. OpenAI says it built Pando as a new backend for Git repositories without interrupting engineering work or changing how its team uses Git, and that it now powers all development in the company’s monorepo.

The story isn’t really about storage design. It’s about where the bottleneck goes once AI agents start doing most of the typing.

What is Pando?

Pando is OpenAI’s in-house, Git-compatible server backend. Engineers and agents still use the normal Git client and commands. What changed is everything behind the server: how it accepts pushes, tracks branches, and sends data back to people fetching code.

The name fits. Pando is also a famous grove of quaking aspen in Utah, thousands of trunks sharing one underground root system and counted as a single organism. Many branches, one root, which is a neat summary of a monorepo.

The problem: Codex created a traffic jam.

With Codex, one engineer no longer works on one change at a time. They may push several changes to CI at once, and each push can kick off multiple jobs that all fetch the same commit.

According to OpenAI’s figures, commits landing on its main branch grew 1,378% between early 2024 and the third quarter of 2026, with most of that jump happening this year. From around the end of 2025, the old system showed strain: slow pushes and fetches, failed merges, and reliability that sometimes dipped below 90%.

OpenAI looked at two standard ways to scale a Git service: replicating every update across most servers or funnelling every push through one shared log. Both share the same weakness. Every push, even to a branch nobody else is touching, still has to queue at one central coordination point. That works with hundreds of humans. It doesn’t hold up with thousands of agents.

How Pando fixes it: two deliberate trade-offs

Pando’s design rests on giving up guarantees that traditional Git servers protect, but OpenAI argues nobody actually depended on that.

1. Branches move independently. Pushes to unrelated branches proceed in parallel, while pushes to the same branch still get a strict order. The trade-off is that a client reading several branches at once may see them at different points in time rather than as one consistent snapshot. OpenAI calls this causal consistency. In practice, developers care about the order of updates on their own branch, not a perfect repository-wide timeline.

2. Data is packaged once and reused. A normal Git server builds a fresh compressed bundle (a packfile) for every client that asks. Pando keeps every pushed pack in blob storage and simply hands readers links to the packs they need. The Git client tells Pando which commits it has and which it wants, and Pando returns links to stored packfiles that cover the gap. When dozens of CI jobs fetch the same commit, that turns expensive work into cheap cache hits.

To stop clients from downloading thousands of tiny packs, background workers steadily merge small packs into larger ones. Pushes also stay lean: the median push pack was under 20 KiB, and the 99th percentile was under 3 MiB.

The results

The numbers OpenAI reports from production are striking:

• Push latency: median push latency fell by nearly 80% compared with the previous backend

• Volume: close to a petabyte of Git data served every day, using only a handful of CPU cores

• Peak load: more than 57 terabytes of Git packs served in a single hour, with over 99% coming from local disk cache

• Concurrency: many thousands of clients can push at the same time without slowing each other down

OpenAI also published a simulation comparing Pando to the conventional designs but labels it a teaching model rather than a benchmark. The production figures above are the ones that count.

Built by agents in 10 weeks

The most quotable part is how Pando got built. OpenAI says it used Codex to go from kickoff to production in just 10 weeks: one engineer designed the core, teams of agents implemented it, a handful of engineers deployed it, and it began serving production traffic in April.

Speed is only half the story. The safeguards are what made agent-written infrastructure trustworthy:

• A fresh codebase in Rust with no legacy dependencies

• A Git conformance test suite so agents could check their changes against standard Git behaviour

• Deterministic simulation testing to catch race conditions

• Formal specifications and continuous red-teaming by agents

The migration used the same approach. Pando first sat as a proxy in front of the old system so traffic moved over with no downtime. OpenAI also gave Codex dedicated skills to prepare existing checkouts and guide agents onto the new system, so developers could migrate their environments just by asking Codex.

Why this matters if you build with AI agents

You probably don’t run a monorepo at OpenAI’s scale. The lesson still applies.

The bottleneck moves downstream. When agents multiply how much code one person produces, shared systems like source control, CI pipelines, and code review become the limit. OpenAI simply hit that wall first.

Question inherited guarantees. Pando’s biggest win came from dropping a property (repository-wide consistency) that cost a lot and protected almost nothing anyone used. Most infrastructure has a few of these.

Design for repeated reads. Agent workloads are repetitive: many jobs fetching the same thing. Caching and reuse pay off far more than they used to.

Keep the interface familiar. OpenAI changed the engine and left the steering wheel alone. Nobody had to learn new commands, so the switch caused no disruption.

Verification is the real enabler. Ten weeks is impressive, but conformance tests, simulations, and formal specs are what let a small team trust code mostly written by agents.

What we still don’t know

• Public availability: Pando is internal. The report does not announce public availability of the backend, though OpenAI says it is exploring ways to share the technology with users.

• What’s open source: OpenAI’s Git client fork is public source code, and some of its fixes have gone upstream to Git. Pando itself is not.

• Cost and infrastructure: no figures on running cost, compute used by the agents, or which cloud and blob store sit underneath.

• What’s next: OpenAI is exploring other internal uses, including workloads where large numbers of agents collaborate on a shared Git repository.

Image Credits: Samuel Boivin/NurPhoto via Getty Images