OpenAI rebuilt its Git backend to keep one giant monorepo fast

A company's source code is boring until it stops working, and OpenAI says that is roughly what happened to its monorepo. In Scaling Git at OpenAI, engineers Aaron Friel, Taylor Blau, and Ted Nyman describe how the systems supporting that single large repository began to buckle around the end of last year: fetches and pushes grew slow, and reliability at times dropped below 90%. For a codebase that every engineer touches daily, that is a tax on the whole company.

Their answer is a new backend they call Pando, which now handles all development in the monorepo. The notable part is what did not change: engineers kept using Git exactly as before, and the team says it moved everyone onto Pando without interrupting ongoing work. The design targets two things that pull against each other, horizontally scalable writes so many people can push to many branches at once, and high read throughput so a client can use all of its available network bandwidth. The mechanism is a layered packfile scheme. Each push lands as a small "L0" packfile, and background workers keep merging those into progressively larger "covers," with the monorepo going up to L4. OpenAI reports more parallelism, better merge reliability, and faster publishing of changes as a result.

The forward-looking note is the one worth flagging: OpenAI says it is now exploring Pando for workloads where many agents collaborate on a shared Git repository, not just human engineers.

Why it matters

If you run a large monorepo, the specific bottleneck here, concurrent pushes and read bandwidth, is probably one you will hit too, and the layered-packfile approach is a concrete pattern to study. The agent angle is the longer game: Git was built for humans pushing a few times a day, and tooling teams should start thinking about what it looks like when fleets of agents commit in parallel.