When coding agents open a dozen branches in parallel and every push triggers several CI jobs that fetch the same commit, your source control server stops looking like a tool for humans. OpenAI's engineering post, Scaling Git at OpenAI, describes how its monorepo hit that wall and what the team built in response: Pando, a new Git backend that stays compatible with standard Git clients.

The headline numbers are company-reported: median push latency down by nearly 5x, and close to a petabyte of Git data served per day. The more useful part for developers is the design reasoning, because it shows which guarantees a Git service can drop and which it cannot.

The problem: many writers, many readers

OpenAI says its monorepo systems began struggling around the end of last year. Symptoms were slow fetches and pushes and failed merges, with reliability at times under 90%. The cause was a multiplication of traffic. More branches, more pushes, more merges, and many more fetches from dev environments, research jobs, and CI.

That splits into two scaling dimensions: many writers pushing to different branches, and many readers fetching the same history. Pando targets both.

A quick Git storage refresher

Git keeps two things in sync across replicas. Objects (blobs, trees, commits, tags) are immutable and identified by hash. Refs (branches and tags) are mutable pointers to commits. Objects are easy to replicate because they never change. Refs are hard, because a service has to arbitrate competing updates that try to move the same branch from the same old tip to different new commits. For background on how objects get bundled, see the Git book chapter on packfiles.

What existing distributed Git designs cost

The post compares Pando against two common patterns.

Three-phase commit across full replicas. A push is sent to every replica and a majority must accept it. You get a consistent view of all refs, but refs update one at a time, coordination takes multiple round trips, and replica disk speed sits on the push path. Under load, write latency grows as disks saturate.

Write-ahead log in blob storage. Servers upload packfiles in parallel and order updates through a shared manifest using compare-and-swap. Uploads scale, but every update competes on the one manifest, and each replica must read and index packs from the log. In OpenAI's simulations, this shows up as read latency.

How Pando works

Pando's central trade is explicit. It gives up a consistent point-in-time snapshot of every ref in the repository, and in exchange it scales writes and reads.

Writes: per-ref causal consistency

On a push, Pando stores the incoming packfile as an immutable blob. It then records a ref version in a metadata store, containing the new tip, the pack, and its dependencies. This gives serializability for updates to a single ref. Two clients conflict only if they push the same ref at the same time. Pushes to unrelated branches proceed in parallel with no shared choke point.

The cost is a weaker read guarantee. A client reading several branches cannot assume those reads describe one moment in time across the repository. For most workflows, such as feature branches and CI, that is fine. For tooling that assumes an atomic view of all refs, it is a real behavioural change worth auditing.

Keeping ref advertisement constant

Git normally advertises refs at the start of a push or fetch. With huge numbers of branches, that list becomes a bottleneck. Pando advertises only a selected set. For a new feature branch, it advertises a designated trunk branch as the base, so the advertisement stays constant-size as branches accumulate. The post says this also makes packfile reuse predictable. The team also mentions contributing the concept of "explicit haves" to Git, letting servers advertise branch tips separately from history.

Reads: reuse packfiles instead of building one per client

Stock Git typically computes a pack tailored to each client's have/want negotiation. Pando uses the commit mappings recorded at push time to look up what the client has and needs, then returns download links through Git's packfile-uri mechanism. Clients pull precomputed packs from a cache-friendly service, and OpenAI says regional caches let it saturate 10 Gbps links.

Compaction, in the style of an LSM tree

Many small pushes produce many small packs, which hurts compression and negotiation. Background workers merge them geometrically, from L0 packs up to L4, much like compaction in a log-structured merge-tree. Fewer, larger packs improve compression and time to first byte.

How it was built and verified

OpenAI says Pando took 10 weeks to build in Rust. Validation combined a conformance test suite with deterministic simulation testing. The team also says agents using GPT-6 Astra wrote Lean and TLA+ specifications to formalize properties of the system, and that agents red-teamed Git and Pando continuously. Treat the formal-methods claim carefully: the post describes the approach but does not publish the specifications or say what bugs they found.

Deployment started as a read- and write-through proxy in front of the existing system, with clients migrated in phases through an internal wrapper around the Git CLI. After rollout, the post reports improved merge reliability, median push latency cut by nearly 80% (consistent with "nearly 5x"), and over 57 TB of packs served in a single hour at cache hit rates above 99%.

Tradeoffs and open questions

  • Single-workload evidence. All results come from one monorepo with unusually heavy agent-driven traffic. There is no comparison across repository shapes or ordinary human-scale workloads.
  • Self-reported. No independent benchmark exists, and the post gives no tail-latency or cost breakdown beyond "a handful of CPU cores" for the petabyte-per-day figure.
  • Weaker cross-ref semantics. Anything that needs an atomic multi-branch view, such as certain release or mirroring tools, must tolerate per-ref ordering.
  • Not available yet. OpenAI only says it is exploring ways to share the technology with the open-source community. Today you can't run Pando.

What to take away

Even without the code, three ideas transfer. First, ask which consistency guarantee your workload actually uses, because "global snapshot of all refs" is rarely one of them. Second, immutable data (packs) should be separated from mutable pointers (refs) so each can scale with the right mechanism. Third, reuse beats recomputation on the read path when many clients ask for the same thing, which is exactly what CI fan-out does.

The upstream Git contributions are the part most likely to help everyone sooner: packfile-uri fixes for interrupted and resumable downloads, better tracing, and explicit haves. If your own CI is fetch-bound, those are worth watching.