OpenAI rebuilds its Git backend to handle more parallel work from Codex

OpenAI’s engineers and coding agents can now push changes to unrelated code branches in parallel without abandoning their Git workflows. In a November 2 engineering disclosure, the company introduced Pando, the backend now powering all development in its shared code repository. OpenAI says the system cut median push latency by nearly fivefold.

The pressure came from Codex enabling more work at once. OpenAI says that meant more branches, uploads of code changes, merges and downloads from development environments, research jobs and automated checks. One engineer could have several changes ready for continuous integration, or CI—the automated checking stage—and each upload could trigger several jobs downloading the same revision.

Around the end of last year, the systems serving OpenAI’s monorepo—a single repository holding its code—began struggling. Fetches and pushes slowed, merges failed, and reliability sometimes fell below 90%, the company says. Its response was to replace the serving backend rather than change how engineers and agents use Git.

Separate branches, separate update queues

Pando’s first decision is to coordinate each branch independently. A branch is a reference pointing to a particular code revision. Systems that put every repository update into one shared order can make changes to unrelated branches wait on each other. Pando instead makes writers compete only when they try to update the same reference simultaneously.

On a push, Pando stores the incoming compressed bundle of Git objects, called a packfile, in blob storage. It separately records the branch’s new revision, the bundle that supplied it and earlier versions it depends on. Both storage layers can grow across more machines. A reader then receives the bundles needed to reconstruct the history behind the requested revision.

The tradeoff is a weaker guarantee across the whole repository. Reading one branch gives the history needed for that revision, but reading several branches does not produce a single synchronized snapshot. OpenAI calls this causal consistency: readers observe the history behind a writer’s update, without requiring every other branch to line up at the same moment.

Send the same bundle to many readers

The second decision changes downloads. Git can tailor a packfile to each client, excluding objects that client already holds. That saves transferred data but costs server processing and disk work. Pando reuses packfiles across requests instead, letting servers and caches deliver identical bytes to many readers with little computation. Some clients receive objects they already have.

Pando also shapes the bundles produced during uploads. A push to the main development branch adds an incremental pack. A push to a side branch includes that branch’s earlier commits again, so a client with the advertised main-branch version can fetch the side branch in one pack. That arrangement favors bundles that can be shared easily.

Why adding storage was not enough

OpenAI evaluated two other designs. One kept complete repository replicas and coordinated updates through multiple communication rounds. Another uploaded packs in parallel but published updates through a shared record in blob storage. In the latter design, unrelated branches still competed to update that record. More storage capacity alone would not remove the coordination bottleneck.

Pando retains compatibility with the Git protocol and client, and OpenAI says it deployed the backend without interrupting engineering work. The company also intends to contribute improvements from its own copy of Git upstream, making client-side changes useful beyond its internal infrastructure.