← Back to feed

OpenAI has replaced the server side of Git for its own monorepo. The system, called Pando, has carried all development traffic since April 2026 and cut median push latency by nearly 5x (about 80%). OpenAI published the architecture on November 2 after a year in which agent-driven commit volume pushed the previous setup into failure.

The trigger was Codex. More engineers running more parallel changes meant more branches, more pushes, more merges, and more fetches from CI, research jobs and dev environments. One push can fan out into several jobs fetching the same commit. From around the end of 2025, the monorepo’s source-control systems showed slow fetches and pushes and failed merges, with reliability at times below 90%.

Key Numbers

• Median push latency: down nearly 5x after cutover
• Post-merge reliability: 99.99% after cutover (previously dipping below 90% at times)
• Throughput: nearly 1 PB of Git data per day; 57+ TB served in a single hour
• Cache efficiency: more than 99% of those bytes served from local disk cache; Express pack-cache hit rates above 99%
• Network: clone and fetch saturate 10 Gbps links on standard cloud VMs
• Build time: kick-off to production in 10 weeks; production traffic since April 2026
• Typical push size: median packfile under 20 KiB, 99th percentile under 3 MiB

What Pando gives up

Pando keeps the Git protocol and client unchanged. It changes two assumptions that most Git servers treat as fixed.

Repository-wide consistency is gone. Conventional designs order every ref update across the repository, so pushes to unrelated branches queue behind each other. OpenAI modelled two standard approaches: three-phase commit across full replicas, and a write-ahead log in blob storage. In its simulation of 1,000 clients each pushing to a distinct branch, the first saturates replica disks on writes and the second saturates readers replaying the journal. Pando instead records a “ref version” per push in a metadata store and guards only the ref pointer with a compare-and-swap. Clients conflict only when pushing the same ref.

The cost is causal rather than global consistency. A client reading several branches cannot assume they reflect a single point in time. Two clones negotiating at once may see branches foo and bar at different versions. OpenAI’s bet is that agents and engineers depend on the order of updates to a single ref, not a global ordering.

Packfiles are shared, not built per client. Pando streams an incoming pack straight into blob storage after one-pass validation, with no unpacking into a local repository. On fetch it selects stored packs covering the client’s have and want sets and returns them through Git’s packfile-uri mechanism, with an empty pack inline. Servers mostly negotiate and select, so they run on commodity hardware.

The ref advertisement trick

A normal Git server advertises every branch on push so the client can exclude objects the server already holds. With millions of branches, that advertisement alone can exceed 100 MiB. Pando advertises only a designated trunk branch by default.

That keeps advertisement size flat as branches multiply, and makes each client’s pack depend only on trunk, so the same pack can be served to any reader who has trunk history. The tradeoff: repeated pushes to one branch, or stacked feature branches, resend objects outside trunk. OpenAI judged the sub-20 KiB median pack an acceptable price.

OpenAI also added “explicit haves” to its Git fork so a server can advertise a branch tip separately from history the pusher may omit, enabling --force-with-lease against trunk-only packs.

Compaction

Each push produces an L0 pack. Background workers merge runs of ref versions into geometrically larger covers, borrowing from log-structured merge-tree compaction. The monorepo uses up to L4. Covers also act as a skip list over ref versions, so pack planning scales logarithmically with how far behind a client is. Without this, a client would download tens of thousands of packfiles a day to catch up on trunk. Packs at every level are retained rather than garbage collected.

Built by the thing it serves

The core design came from one engineer; teams of agents implemented it and a handful of engineers deployed it. It is written in Rust with no legacy dependencies. A conformance suite checks behaviour against standard Git, and deterministic simulation harnesses hunted race conditions in negotiation and pack planning. Using GPT-6 Astra, agents wrote Lean and TLA+ specifications of Pando, which were used to find bugs and prove properties. Some sessions ran continuously for hundreds of hours.

Rollout started with Pando as a read- and write-through proxy in front of the old system, which let traffic move one workload at a time without downtime. Codex itself migrated checkouts and services using purpose-built skills. Hundreds of integrations tied to legacy APIs, webhooks and repository downloads moved alongside.

What to watch

OpenAI says it is exploring ways to share the technology externally and is already upstreaming client fixes to Git, including packfile-uri tracing and download handling. It is also looking at Pando for workloads where many agents collaborate on one repository. No release date or licensing was given. For anyone running agent-heavy workflows on a conventional Git host, the failure mode OpenAI describes (write contention on a single ordering point, per-client pack generation on reads) is the one to benchmark first.