Git was born in an era of sending patches to the kernel over email, and for more than two decades developers adapted their tooling around it. But an OpenAI engineering retrospective makes something else clear: once the primary author of code shifts from humans to agents, the default assumptions baked into Git's server side collapse all at once.
The server side is what broke
OpenAI's monorepo is mostly Python, plus Rust and Go services. Codex changed the scale and pace of development: branch creation, pushes, merges, plus fetches from dev environments, research jobs and CI all multiply. One engineer might have several changes queued for CI at once, and a single push can leave several jobs fetching the same commit. Starting around the end of last year the backend began to struggle: slow fetches, slow pushes, failed merges, with reliability at times falling below 90%.
There are broadly two conventional ways to scale a Git service, and OpenAI evaluated both. Three-phase commit keeps a complete copy of the repository on every replica and needs a majority of replicas to accept a ref update before publishing it; reads can be served locally and clients get a consistent view of all references, but each push needs multiple round trips among replicas. A shared write-ahead log records all ref updates in one manifest, swapped atomically via compare-and-swap; writes can upload in parallel, but pushes to unrelated branches still contend for that one manifest.
Pando's choice is explicit: give up repository-wide consistency in exchange for causal consistency.
Trading consistency for branch-level parallel writes
Pando records every branch move as a ref version — the new tip, the pack that supplied it, and whichever earlier ref versions that pack depends on — written into a metadata store, while the packfile itself is kept as an immutable blob in blob storage. Both stores scale horizontally. On the write path, Pando streams the incoming packfile into blob storage while validating it with a single decode pass, without unpacking it into a local repository. It then uses a multi-key transaction to record the ref version and atomically update the ref pointer, which also yields read-your-own-write consistency. The entire write operation requires a constant number of metadata reads and writes.
The tradeoff is written plainly: when reading several branches, a client cannot assume those reads describe a single point in time. But pushes to unrelated branches proceed fully in parallel; only concurrent pushes to the same ref can conflict.
One easily missed detail: in the Git protocol the server advertises every ref to the client, and with millions of branches that advertisement alone can exceed 100 MiB. Pando advertises only a selected set of refs, and by default a push of a new feature branch advertises just the designated trunk branch as a base. The cost is that repeatedly pushing the same branch forces the client to resend everything outside trunk; the payoff is that packfiles produced in this monorepo have a median under 20 KiB and a 99th percentile under 3 MiB.
Treating packfiles as a CDN cache
On the read path, Pando no longer generates a fresh packfile per client. It uses the commit mappings recorded at push time to resolve the client's haves and wants into a set of ref versions, selects the stored packfiles covering those objects, and returns packfile URIs for the client to fetch. The Git protocol only allows a single packfile in the HTTP response for a fetch, but the packfile-uri mechanism lets a server return links to additional packs — so Pando uses that exclusively, transmitting an empty packfile inline while the real bytes travel through a separate service called Express, which caches the blob store in each region, routes with consistent hashing, and reports cache hit rates over 99%. Using only standard cloud provider virtual machines, clone and fetch operations saturate 10 Gbps network links.
Too many small packfiles is a separate problem: sending one URI per push would force a client to download tens of thousands of files just to catch up on trunk. Pando merges packfiles into covers in the background, scaling geometrically from L0, and the trunk currently uses up to L4 — a design closely resembling compaction in log-structured merge trees. Covers also act as a skip list over ref versions, letting fetch planning select packs in logarithmic time; packfiles at every level are kept rather than garbage collected, because reading an arbitrary object from L0 tends to move less data than from L4. The result: more than 57 TB of Git packs served in a single hour, with over 99% of those bytes coming from local disk cache.
Building Codex's infrastructure with Codex
Pando took ten weeks from kick-off to production. The core was designed by a single engineer, implemented by teams of agents, and deployed by a handful of engineers; it began serving production traffic in April. It is written in Rust with no legacy dependencies. So agents could verify their own work, the team first wrote a conformance test suite that checks behavior against standard Git, and also built deterministic simulation testing harnesses to check system invariants.
Using GPT-6 Astra, agents wrote Lean and TLA+ to formalize a "theory of Pando," which they used to find and fix bugs in the implementation and prove properties of the system. Multiple continuous sessions ran for hundreds of hours hunting edge cases, and agents run around the clock red-teaming Git and Pando with Daybreak-capable models. Deployment started as a read- and write-through proxy to the existing source control system, so traffic could move without downtime.
Giving back upstream, and the so-what
Client-side bugs surfaced while working on Pando were fixed and pushed upstream to Git: concurrent downloads, cleanup after interrupted transfers, resuming downloads that had already completed, and validation when accepting an existing pack for a fetch. The team also contributed the concept of "explicit haves" — a server can advertise a branch's current tip separately from history that a pushing client may leave out of its pack, which lets clients use --force-with-lease to check a feature branch has not moved and build its pack against trunk alone. Some of these improvements are already in upstream Git.
The real significance may not be Git itself. Two decades of Git server evolution assumed one person writes and one person pushes; when agents raise branch counts, push frequency and concurrent fetches at the same time, what breaks is the server side, not the client. OpenAI simply abandoned repository-wide consistency and accepted causal consistency, which tells you that in their real workloads, global ordering of ref updates has become unimportant enough to sacrifice — a very concrete signal that machine-driven work is taking over. A second layer is more striking: ten weeks, one designer, agent implementation. This infrastructure was itself written by agents, including the Lean and TLA+ used to prove the system correct. The bottleneck has shifted from whether the model is strong enough to how the system is designed and who reviews it.
Pando is not open source today, with no public API or deployment guide, so the only thing outsiders can directly take away are the Git client patches pushed upstream. The more actionable lesson for teams of comparable scale: measure how many assumptions in your toolchain are shaped like "one person, one branch at a time."
For the original technical details, see OpenAI's engineering post Scaling Git at OpenAI (https://openai.com/index/scaling-git-at-openai/); independent cross-verification of the key metrics appears in AlphaSignal's coverage (https://alphasignal.ai/news/openai-s-pando-cuts-push-latency-80-serving-a-petabyte-of-git-daily).