OpenAI Built a New Git Backend, Pando, to Handle Agentic-Scale Code

OpenAI has replaced the backend of its monorepo with a new system called Pando that cut median push latency by nearly 5x and now delivers nearly a petabyte of Git data per day, the company said in an engineering post titled "Scaling Git at OpenAI." The rewrite, built in just 10 weeks with help from OpenAI's own AI models, kept the Git client and protocol intact while discarding two assumptions most Git infrastructure treats as mandatory.

The stakes are straightforward: AI coding agents such as Codex multiply the volume of branches, pushes, merges, and fetches far beyond what human-only teams produce. OpenAI says its previous monorepo infrastructure, starting around the end of last year, suffered slow fetches and failed merges, with reliability at times falling below 90%. Every team running agent-heavy development will eventually hit a similar wall.

Why did OpenAI need a new source-control backend?

OpenAI frames the problem bluntly. "It was clear that we needed to revamp our source control system to scale to the level of concurrent work that Codex makes possible," the company wrote. Codex lets one engineer have several changes ready for CI at once, and each push can trigger several jobs fetching the same commit across development environments, research jobs, and CI. Those demands compound.

The team faced a choice: abandon Git or rebuild what sits behind it. They chose the latter, partly on principle. Git grew out of a community that exchanged kernel patches via email, and for more than two decades developers have adapted their tools around it. "Building on Git as the foundation of our source-control workflow meant that improvements to the client could be useful beyond OpenAI," the post notes. OpenAI says it wants to contribute those improvements from its public Git fork back upstream.

In short: OpenAI kept the interface and replaced the engine, and the engineering work is already flowing back to the open-source Git community.

What is Pando, and how does it scale?

Pando is a backend for Git repositories with two goals: horizontally scalable writes, optimized for concurrent pushes to many branches, and maximum read throughput so clients can saturate their available network bandwidth. It now powers all development in OpenAI's monorepo.

The design rests on two deliberate compromises:

• Relaxed repository-wide consistency. Pando coordinates updates to each branch independently, providing causal consistency rather than a point-in-time snapshot of all refs (branch pointers). A reader looking at several branches may see them at different moments. OpenAI argues users and agents in practice depend only on the ordering of updates to a single reference. Individual refs remain serializable, and clients conflict only when pushing to the same ref simultaneously.
• Reused packfiles. Conventional Git servers generate a unique packfile (Git's format for compressing multiple objects together) for each fetching client, which costs CPU and disk I/O. Pando instead serves the same stored packfiles to many clients, accepting that a client may re-download some objects it already has.

Each push stores its incoming packfile as an immutable blob in blob storage. Pando records a "ref version" — the new tip, the pack that supplied it, and its dependencies — in a horizontally scalable metadata store. The write path needs only O(1) metadata reads and writes; a fetch plan needs O(log Δ) metadata reads, where Δ is the distance in ref versions between what the client has and what it wants.

The takeaway: Pando buys scale by weakening guarantees almost nobody actually uses.

How does it compare with conventional approaches?

OpenAI modeled two standard architectures before building Pando. The first, three-phase commit (3PC, a protocol for coordinating a commit across multiple nodes), keeps full replicas of the repository and requires a quorum to accept each ref update. That guarantees clients a consistent view of all references from any replica, but it puts disk performance and communication latency on the push path, and pushes to unrelated branches can wait on one another.

The second approach orders updates through a shared write-ahead log (WAL, a record of changes written before they're applied) in blob storage, published via a compare-and-swap operation. Writes can upload packfiles in parallel, but every push — even to unrelated branches — must update the same manifest, and the compare-and-swap round trip caps publication rate. Replicas also fall behind when indexing can't keep up with writes.

In a simulation with 1,000 clients each pushing unique commits to distinct branches, the 3PC design showed significantly greater write latency as disks saturated, while the WAL design showed significantly greater read latency. Pando, in both the simulation and real-world monorepo testing, supported many thousands of concurrent pushing clients without performance degradation under load.

The tradeoffs are real, though. Pando's ref advertisement strategy — showing clients only a designated trunk branch rather than all refs — makes successive branch pushes larger and potentially redundant. OpenAI reports median packfiles under 20 KiB and the 99th percentile under 3 MiB, which it calls a sensible trade-off. With millions of branches, a full ref advertisement alone can exceed 100 MiB, so the constraint is not arbitrary.

The bottom line: Pando wins by refusing to coordinate what doesn't need coordinating.

What are the production numbers?

The reported figures are unusually concrete for an infrastructure announcement:

• Median push latency reduced by nearly 80%.
• Nearly a petabyte of Git data delivered per day, using just a handful of CPU cores.
• More than 57 terabytes of Git packs served in a single hour, over 99% of it from local disk cache.
• Cache hit rates above 99% via consistent hashing to Express, the pack delivery service.
• Clone and fetch operations saturating 10 Gbps network links on standard cloud virtual machines.
• Production traffic since April of this year.

Pando runs three services: pushes, fetches, and compaction. Compaction borrows from log-structured merge-trees, grouping small "L0" packfiles into geometrically scaled covers up to L4. Unlike most Git servers, Pando keeps packfiles at every level rather than garbage-collecting them, and the covers double as a skip list so fetch planning scales logarithmically. That matters because a fast-moving repository could otherwise force clients to download tens of thousands of packfiles per day just to catch up on trunk.

How was it built — and what did agents do?

OpenAI describes the construction of Pando in terms that double as an AI capability claim. The core design came from a single engineer; implementation was done by teams of agents; deployment was handled by a handful of engineers. Kick-off to production took 10 weeks.

Validation leaned heavily on automation. OpenAI wrote a conformance test suite so agents could check changes against standard Git behavior, plus deterministic simulation harnesses to catch race conditions in negotiation and pack planning. Agents using GPT-6 Astra wrote Lean and TLA+ specifications — formal methods for proving system properties — to build a "theory of Pando," finding and fixing bugs. Continuous agent sessions ran for hundreds of hours, and OpenAI runs agents around the clock to red-team Git and Pando with Daybreak-capable models. Pando itself is written in Rust with no legacy dependencies.

These are OpenAI's own claims without independent verification; the performance numbers come from OpenAI's production deployment, not third-party benchmarks.

Migration ran through a read- and write-through proxy that kept Pando and the old system in sync, allowing traffic to move without downtime. OpenAI shipped its public Git distribution to developer machines and inside the ChatGPT desktop app, migrated hundreds of integrations off legacy APIs and webhooks, and let developers ask Codex to migrate their own environments.

What flows back to Git itself?

Building Pando surfaced upstream work. OpenAI contributed improvements to packfile-uri, an under-appreciated Git protocol feature that lets a server return links to additional packs; Pando uses it exclusively, sending an empty packfile inline. OpenAI's Git build can download and index independent packs in parallel, and it adds "explicit haves" so clients can use --force-with-lease against trunk alone. Several improvements are already in upstream Git, with more in OpenAI's public repository and patch tracker.

OpenAI says it is exploring ways to share Pando's technology with its users, including workloads where large numbers of agents collaborate on a shared repository. The company's wager is that the concurrency limits it hit will become the norm: as engineers and agents produce more software in parallel, more teams will find that Git's 20-year-old workflow survives, but the assumptions underneath it do not.