OpenAI Rebuilt Git's Backend for Codex Agents, Cutting Push Latency Nearly 5x

OpenAI has rebuilt the system that stores and serves the code in its main monorepo, because its own coding agents were pushing more changes than a conventional Git server could handle. In a technical write-up published on November 2, 2026, the company said its new backend, called Pando, cut median push latency by nearly five times and now delivers close to a petabyte of Git data a day.

The striking part is what did not change. Engineers and Codex agents still use ordinary Git commands, and the company kept full compatibility with the Git protocol and client. For any team whose repositories are starting to creak under AI-assisted development, Pando is a detailed look at where Git servers break first, and what OpenAI traded away to fix it.

Key facts at a glance

• Pando now powers all development in OpenAI's monorepo and began serving production traffic in April 2026.
• Median push latency fell by nearly 80%, which OpenAI describes as close to a fivefold improvement, and merge reliability improved.
• Reliability had at times dropped below 90% on the previous setup, with slow fetches, slow pushes and failed merges.
• One engineer designed the core, teams of Codex agents implemented it in Rust, and the project went from kick-off to production in 10 weeks.
• Pando itself is not being open-sourced, but OpenAI says several client fixes are already in upstream Git and more sit in its public Git repository.

Why coding agents broke the old setup

OpenAI says the size of and demands on its monorepo grew "at a staggering pace" over the past year. The cause was Codex, its coding agent, which lets each engineer run far more work in parallel. That means more branches, more pushes, more merges and many more fetches and clones from development environments, research jobs and continuous integration (CI) systems.

The load compounds. The company explains that one engineer may now have several changes ready for CI at once, and each push can trigger several jobs that all fetch the same commit. OpenAI has also said that, compared with the first quarter of 2024, quarterly commits to its monorepo will have risen by more than 2,400% by the end of 2026.

Starting around the end of 2025, the systems behind the monorepo struggled to keep up. OpenAI's engineers, Aaron Friel, Taylor Blau and Ted Nyman, framed the key question as whether they had hit "a limit of Git itself, or of the way we served our monorepo". They concluded the bottleneck was the server design, not Git, so they kept the familiar workflow and rebuilt what sits behind it.

That choice matters for everyone else. Because Pando speaks standard Git, the fixes OpenAI made to the Git client while building it can, in principle, help every Git user rather than only OpenAI.

How Pando works: two rules it deliberately breaks

Most Git servers treat two things as requirements. OpenAI decided both were optional for its workload.

No single, repository-wide snapshot

Conventional servers order every branch update across the whole repository. OpenAI's write-up compares two common designs it modelled: three-phase commit, where a majority of full replicas must agree on each change, and a shared write-ahead log in blob storage, where every push competes to update one manifest. In both, a push to one agent's branch can end up waiting on a push to a completely unrelated branch.

Pando instead coordinates each branch on its own. Updates to unrelated branches proceed in parallel, and the only contested piece of data is the pointer to a branch's latest commit, guarded by an atomic compare-and-swap style operation. OpenAI calls the result causal consistency: a reader of a branch sees the history its writer saw.

The trade-off is that a client reading several branches may see them at slightly different points in time. OpenAI argues that, in practice, people and agents care about the order of updates to a single branch, not a global order across millions of branches.

No custom pack for every client

When a client fetches code, a normal Git server works out exactly which objects that client lacks and compresses a fresh "packfile" (Git's bundle format for compressed objects) just for it. That is expensive and hard to cache.

Pando reuses the packs clients already pushed. When a push arrives, Pando validates the pack while streaming it into blob storage, without unpacking it into a local repository, and records the new branch tip and its dependencies in a metadata store. To make those packs reusable, it advertises only a designated trunk branch as the base for new feature branches. OpenAI says the median pack produced this way in its monorepo was under 20 KiB, and the 99th percentile under 3 MiB.

On a fetch, Pando picks the stored packs the client needs and hands back download links using packfile-uri, a little-used feature of the Git protocol. A caching service called Express serves those packs from regional caches with hit rates above 99%, according to the company.

Source: OpenAI's technical description of Pando, November 2, 2026.

The numbers OpenAI reports

For platform engineers, the production figures are the most useful part of the write-up.

• Push latency: the median push is nearly 80% faster since the switch.
• Throughput: close to a petabyte of Git data a day, with "just a handful of CPU cores" doing the serving work.
• Peak hour: more than 57 terabytes of Git packs served in a single hour, with over 99% of those bytes coming from local disk cache.
• Network speed: on standard cloud virtual machines, OpenAI says clones and fetches saturate 10 Gbps links.
• Simulation: in its own modelling, the company configured 1,000 clients each pushing to a distinct branch and found Pando kept performing under load where the other two designs slowed.

Compaction keeps busy clients fast. In a repository this active, a client catching up on a day of trunk changes could otherwise need tens of thousands of tiny packs. Pando merges them in the background into larger "covers", in a scheme OpenAI likens to log-structured merge trees, and today uses up to four levels above the original push packs. Those covers also let it plan a fetch in logarithmic time.

OpenAI is clear that the simulation results are synthetic teaching models, not production benchmarks, so the production figures above are the ones to weigh.

How it was built and rolled out

Agents did much of the engineering. OpenAI says Pando was built with Codex in 10 weeks, written in Rust without legacy dependencies, and validated with a Git conformance test suite and deterministic simulation testing. Using its GPT-6 Astra model, agents wrote Lean and TLA+ specifications, two tools for formally describing and proving how a system behaves, to find and fix bugs. The company says it also runs agents around the clock to red-team Git and Pando.

The migration avoided downtime. Pando first ran as a read- and write-through proxy in front of the old source control system, so traffic could move across gradually. OpenAI shipped its own Git build to developer machines and inside the ChatGPT desktop app, migrated hundreds of integrations that relied on older APIs and webhooks, and wrote Codex skills so developers could ask the agent to move their own environments.

Another view: not everyone is keeping Git

OpenAI's choice stands out because others are taking a different road. Anthropic has built its own replacement for Git, called Scion, with a new client and architecture, and has said it has no plans to release it. Startups are also rethinking source control for AI-heavy teams.

Pando's own trade-offs are real. Advertising only trunk means repeated pushes to the same branch, or branches stacked on other branches, resend everything not on trunk, which costs extra client bandwidth. OpenAI accepts that because its packs stay small, but a team with large binary assets or deep branch stacks might see a different balance. And since Pando stays in-house, other companies get the ideas and the upstream Git fixes, not the software.

What it means for you

For most developers in the US, UK, Canada and Australia, nothing changes tomorrow: your Git commands work the same, and Pando is not a product you can buy. The practical value is in the lessons and the upstream fixes.

• If you run a busy monorepo with AI agents, watch for the same early warnings OpenAI saw: slow fetches, failed merges and CI jobs repeatedly fetching the same commit.
• If you manage CI, the finding that each push can fan out into several fetches of one commit suggests that caching and fetch deduplication may pay off before any backend rewrite.
• If you contribute to or depend on Git, OpenAI's work on packfile-uri, including fixes for concurrent downloads, cleanup after interrupted transfers and resumed downloads, plus new tracing for pack downloads, is being offered upstream.
• If you lead engineering, the story is a concrete example of AI agents changing infrastructure needs, not just coding speed.

What happens next

OpenAI says it is exploring other internal uses, including workloads where large numbers of agents collaborate on one shared repository. It also says it is "exploring ways to share the technology that makes Pando possible" with its users, without committing to a product or a date.

Two open questions are worth tracking. The first is how many of OpenAI's client changes, such as parallel pack downloads and a new "explicit haves" feature for pushes, the Git project accepts upstream. The second is whether OpenAI turns Pando's approach into something customers can use alongside Codex.

Takeaways

1. Measure before you migrate. Track push latency, fetch times and merge failures so you know whether agent-driven load is actually hurting your repositories.
2. Look at fan-out first. Reduce how many CI jobs fetch the same commit, and cache what they fetch, before considering a new backend.
3. Keep Git if you can. OpenAI's experience suggests server design, not the Git protocol, is usually the limit, and staying compatible keeps your tools working.
4. Follow upstream Git releases. Improvements to packfile-uri and pack downloads could speed up clones and fetches for everyone who adopts them.