OpenAI builds Pando, a new Git backend, to scale its monorepo for agent-driven work

OpenAI built a new backend for its Git monorepo after Codex-driven development pushed the existing source control system past its limits, with reliability at times dropping below 90%. The system, called Pando, now handles all development in the company's monorepo without changing how engineers or agents use Git. In production it cut median push latency by nearly 5x and serves close to a petabyte of Git data per day.

OpenAI's engineering team described the work in a post co-authored by Aaron Friel, Taylor Blau, and Ted Nyman. The core problem was concurrency: engineers running Codex work in parallel generate more branches, pushes, merges, and fetches from CI, research jobs, and development environments. Each push can trigger several jobs fetching the same commit, and those demands compound.

Two goals, one constraint

Pando targets two things. First, horizontally scalable writes, so pushes to many branches can land at once. Second, maximum read throughput, so clients can download fast enough to saturate their network bandwidth. OpenAI kept compatibility with the Git protocol and client, which meant no retraining and no workflow changes for people or agents.

The team framed the decision as a question of whether they had hit a limit in Git itself or in how they served their monorepo. Git grew out of a community that exchanged kernel patches by email, and OpenAI said it mattered that they could keep building on that work. Building on Git also let the company contribute client improvements upstream.

How Pando handles writes and reads

Pando coordinates updates to each branch independently. Pushes to unrelated branches proceed in parallel, and a reader fetching a branch gets the history needed for that revision. The tradeoff: a reader looking at several branches can see them at different points in time.

On the read side, Pando reuses packfiles across fetches instead of generating a separate packfile for each client. A client may download some objects it already has, but the server sends the same bytes to many clients with little computation. Together, these choices let OpenAI scale writes across branches and serve reads from caches.

The post walks through the two conventional approaches the team evaluated. In a three-phase commit design, the service keeps a full copy of the repository on several replicas, sends each incoming packfile to all of them, and requires a majority to accept the ref update before publishing. That keeps reads local and gives every client a consistent view of all references, but it puts replica disk performance and coordination latency on the push path, and refs update one at a time.

In a write-ahead log design, servers upload packfiles to blob storage in parallel and publish by adding an entry to a shared manifest using a compare-and-swap operation. Writers can upload in parallel, but even pushes to unrelated branches require updating the same manifest, and the round-trip time for a successful compare-and-swap caps how often the repository can publish.

Why this matters for your team

Most organizations won't build a custom Git backend. But the pattern behind Pando is worth watching: AI coding agents multiply branch and push volume, and the bottleneck often lands on shared infrastructure rather than on any single developer's machine. If your team runs agents in CI or parallel worktrees, measure fetch and push latency and failure rates before they become the reason merges stall. OpenAI's numbers - sub-90% reliability at the low point, near-5x faster median pushes after the fix - give you a rough sense of how far a standard Git server setup can fall behind once concurrency climbs.

OpenAI said it will keep contributing to Git to support agent-scale work. The company has not said whether Pando will be released outside its own infrastructure.