OpenAI Pando: The Git Backend It Built for Codex-Scale Work

OpenAI has published how it rebuilt source control for its own monorepo. The new backend is called Pando. It is compatible with Git, it now serves all development in OpenAI's monorepo, and OpenAI says it cut median push latency by nearly 5x. The company also reports that Pando delivers nearly a petabyte of Git data per day.

The reason is Codex. In its Scaling Git at OpenAI post, dated November 2, 2026, OpenAI says the load on its monorepo grew at a "staggering pace" as engineers and agents began running many changes in parallel. Reliability at times fell below 90 percent. This is a rare, first-party account of what coding agents do to infrastructure that was built for humans.

TL;DR: what OpenAI says about Pando

Why did OpenAI need a new source control system?

The problem was volume, not Git. OpenAI says Codex lets one engineer have several changes ready for CI at once, and each push can set several jobs fetching the same commit. Development environments, research jobs and CI all clone and fetch. More branches, more pushes, more merges, more fetches.

The team says systems supporting the monorepo began to struggle around the end of last year. It saw slow fetches and pushes and failed merges. Then it asked a direct question: had it hit a limit of Git itself, or of how it served the monorepo? Its answer was the second. It decided to keep Git as the client-facing foundation and rebuild only the server side, so that improvements to the client could help people outside OpenAI too.

That choice is easy to miss. Many companies at this scale replace Git with a custom version-control system, which then forces every tool, script and agent to relearn it. OpenAI kept the protocol so that existing tools, and the models that already know Git commands well, keep working. For background on why monorepos stress version control in the first place, see our monorepo explainer.

How do conventional Git services scale, and where do they hit limits?

OpenAI modelled two common patterns before designing Pando.

Three-phase commit (3PC). Every replica holds a full copy of the repository. A push is copied to all replicas, and a majority must accept the ref update through several rounds of messages. Reads are consistent and local. But refs update one at a time, and replica disk speed and network latency sit on the push path. As write volume grows, replicas must absorb incoming packs and read traffic at once.

Write-ahead log (WAL) in blob storage. A shared manifest in blob storage orders updates. Writers upload packfiles in parallel, then compare-and-swap the manifest. Even pushes to unrelated branches contend on the same manifest, and each replica still has to read and index packs before it can serve them. Batching helps throughput but adds queueing delay.

OpenAI's post includes an interactive simulation of both designs against Pando. It labels the simulation "synthetic teaching models, not production benchmarks." In that model, 3PC shows much higher write latency under load as disks saturate, and WAL designs show much higher read latency for the same reason. Treat the simulation as an illustration of OpenAI's reasoning, not as proof.

What does Pando do differently?

OpenAI says Pando works because it gave up two things most Git systems treat as required.

1. Repository-wide consistency. A consistent point-in-time snapshot of every ref needs coordination across the whole repository, so pushes to unrelated branches contend on one point. Pando coordinates each branch independently. The trade-off OpenAI names is that a reader looking at several branches can see them at different points in time.
2. A unique packfile for every client. Normally the server computes a custom pack for each client based on what that client already has. That costs CPU and disk I/O. Pando reuses stored packfiles across fetches. A client may download some objects it already holds, but the server can send the same bytes to many clients with little computation.

The write path

When an agent runs git push, Pando streams the incoming pack to blob storage while validating it in a single pass, without unpacking it into a local repository. It then runs a multi-key transaction in its metadata store that records a new ref version and atomically moves the ref pointer. OpenAI says this gives "read-your-own-write" consistency and needs a constant number of metadata reads and writes regardless of push size. The only contended key is the ref pointer, guarded by an atomic compare-and-swap-like operation. More throughput comes from adding Pando servers, metadata store units or blob stores.

A second trick sits in the push itself. A normal Git server advertises every branch, so the client can leave out objects the server has. With millions of branches that advertisement alone can exceed 100 MiB. Pando advertises only a select set, by default one designated trunk branch. The client then builds a pack that depends only on what the server allowed it to exclude, so the server can later reuse that exact pack for fetches.

The cost is bandwidth. If an engineer pushes the same branch many times, or stacks one feature branch on another, the client resends everything outside the trunk. In OpenAI's monorepo the median pushed packfile was under 20 KiB and the 99th percentile under 3 MiB, which it judged a fair trade.

The read path

On fetch, the client sends "haves" and "wants." Pando maps those commit IDs to ref versions and selects stored packfiles that cover what the client needs. It then uses a Git feature called packfile-uri from the Git protocol v2 documentation: the server returns links to additional packs rather than one large inline pack. Pando sends an empty pack inline and links to everything else. OpenAI says it contributed several improvements to packfile-uri upstream.

Packs are served through a service OpenAI calls Express, which caches blob storage in each region. Requests are routed by consistent hashing, with cache hit rates above 99 percent. OpenAI says that on ordinary cloud virtual machines, clone and fetch saturated 10 Gbps links.

Compaction

Because each push makes one small "L0" packfile, a client could need tens of thousands of packs a day to catch up on trunk. Pando therefore merges packs in the background, in the style of log-structured merge-tree compaction, into larger "covers" at levels up to L4 today. The covers improve compression and act as a skip list over ref versions, so pack selection takes logarithmic time in how far behind the client is. Unlike many Git servers, Pando keeps packs at every level instead of garbage collecting them.

What are the results, and how much should you trust them?

All of these come from one company describing its own system. The post gives no baseline for the old backend, no hardware specification for the "handful of cores," and no error bars. The numbers are plausible given the design, but nobody outside OpenAI can reproduce them today. The interactive simulation is explicitly not a production benchmark.

How was Pando built with Codex?

This may be the most quoted part. OpenAI says it moved from kickoff to production in 10 weeks. "The core of Pando was designed by a single engineer, implemented by teams of agents, and deployed by a handful of engineers."

The validation approach is worth studying:

• Rust, greenfield, no legacy dependencies.
• A conformance test suite so agents could check their changes against standard Git behavior.
• Deterministic simulation testing to check invariants and find race conditions in negotiation and pack planning.
• Formal methods. Using GPT-6 Astra, agents wrote Lean and TLA+ to formalize a "theory of Pando," which OpenAI used to find bugs and prove properties. Multiple continuous sessions reportedly ran for hundreds of hours.
• Continuous red-teaming by agents around the clock, using Daybreak-capable models.

This lines up with other OpenAI claims about the same model family. Our coverage of OpenAI's Astra math proofs with Lean certificates shows the same pattern: have the model produce something a checker can verify. Our Daybreak explainer covers the security side of that work. The post does not say how many bugs the formal methods found or how many hours of agent time were used, so the strength of that claim is unknown.

How did OpenAI roll it out without downtime?

Pando first ran as a read- and write-through proxy in front of the existing source control system. Both stayed in sync, so traffic could move system by system. Pando's caching can also deduplicate and combine requests before proxying, which kept the old backend healthy during migration. As workloads moved, their pushes warmed Pando's cache.

To get the best performance, OpenAI began shipping its own Git distribution to developer machines and inside the ChatGPT desktop app, and migrated clients in phases through an internal wrapper around the Git CLI. It migrated hundreds of integrations that relied on legacy APIs, webhooks and repository downloads. Codex helped here too: OpenAI built skills for preparing existing checkouts and for guiding agents, so developers could ask Codex to migrate their environments.

What did OpenAI contribute back to Git?

Pando's design surfaced bugs in Git's own handling of reusable packs. OpenAI says it fixed edge cases in concurrent downloads, cleanup after interrupted transfers, and resuming completed downloads, added validations when accepting an existing pack for a fetch, and added tracing and byte counts for packfile-uri downloads and pack generation.

In its public Git build, the client can download and index independent packs in parallel. It also added "explicit haves," which let a server advertise a branch's current tip separately from the history a pushing client may leave out. On Pando this lets clients use --force-with-lease to check that a feature branch has not moved while building the pack against trunk alone. Several of these changes are in upstream Git, and others are tracked in OpenAI's public patch tracker. The standard git push documentation describes --force-with-lease if you want the baseline behavior.

What this means for teams running coding agents

You probably do not run a monorepo at OpenAI's size. The lesson still applies at smaller scale.

• Agents multiply writes and reads. One person with several agent sessions behaves like a small team. CI and cloud environments fetch the same commit again and again.
• Check your Git host's limits early. Look at push latency, merge failure rate and fetch time per clone, not just uptime. OpenAI saw failed merges and reliability under 90 percent before it acted.
• Short-lived branches and trunk-based flow fit this design. Pando's default of advertising only trunk works best when most branches are small and based on trunk.
• Keep Git as the interface. OpenAI argues that staying compatible let both humans and agents adopt the system with no new training. Our look at git-ai and source control for agents shows the opposite approach, which adds an agent-specific layer on top of Git.
• Expect the platform vendors to follow. If Pando is offered to customers, it would sit beside the agent harness work in Codex as a platform. That is speculation. OpenAI only says it is "exploring ways to share the technology."

What is still open?

• Availability. No product name, date or price. OpenAI says only that it is exploring ways to share the technology.
• Independent validation. No third party has measured Pando.
• The multi-agent use case. OpenAI says it is exploring workloads where large numbers of agents collaborate on one shared Git repository, which would be a harder test than a human-driven monorepo.
• Consistency trade-off. The relaxed view across branches could matter for tools that assume a global snapshot. OpenAI says it was acceptable for its workflow, but gives no list of tools that needed changes.
• Cost. The post says Pando runs on commodity hardware but gives no dollar figure.

For context on how heavily OpenAI's own teams lean on Codex, and on the compute strain that creates, see our report on GPT-6 Astra usage limits and the Astra 28-day sprint log.

Related reading

• Codex as a platform: OpenAI opens its agent harness
• git-ai: open-source source control for coding agents
• What are monorepos?
• OpenAI Astra and ten math proofs with Lean certificates
• OpenAI Daybreak and Codex Security
• GPT-6 Astra usage limits
• Official: Scaling Git at OpenAI and Git protocol v2

Details and figures are accurate as of November 3, 2026, and come from OpenAI's own post. OpenAI may publish more about Pando.