OpenAI Pando: The Git Backend Built for Agent Traffic

Posted on by
Contents show
OpenAI Pando

# OpenAI Pando: The Git Backend Built for Agent Traffic

The commit chart told the story before anyone asked for a new system. Between the first quarter of 2024 and the third quarter of 2026, commits landing on the main branch of OpenAI's monorepo rose 1,378 percent, with the internal estimate for the fourth quarter pointing at 2,442 percent. No reorganization explains that curve. What explains it is Codex: when coding agents run in parallel, every engineer becomes a small fleet, every push triggers a burst of CI fetches, and a source control system designed for human pace finds its limits in a hurry.

By late 2025 the symptoms were conventional and severe: slow pushes and fetches, failed merges, reliability that sometimes dropped below 90 percent. The monorepo had become a shared bottleneck for humans and agents alike, which is exactly the failure shape we described in this survey of agent orchestration systems: the agent layer outruns the infrastructure beneath it. OpenAI's diagnosis is the interesting part. The bottleneck was not Git itself, which has absorbed two decades of adaptation, but the way the monorepo was served.

The answer is Pando, a new Git backend now powering all development in OpenAI's monorepo, and a case study in how agent-era infrastructure gets rebuilt. Engineers and agents run git push and git fetch exactly as before. Only the server changed. Median push latency fell by nearly 80 percent, the Pando system now delivers close to a petabyte of Git data per day, and it reached production in ten weeks, written in Rust, with one engineer designing the core and teams of Codex agents implementing it.

This article unpacks the two assumptions Pando abandons, how the pieces fit together, what the numbers do and do not prove, and what the whole exercise signals for every team whose repository traffic is starting to look like OpenAI's.

Why agent traffic breaks normal Git serving

A human-paced repository and an agent-paced repository differ in kind, not just in volume.

When a person pushes, a handful of CI jobs fetch. When an agent pushes, the push can set off a wave: CI jobs, review environments, research jobs, and other agents that consume the new commit. OpenAI's engineers describe having several changes ready for CI at once, each push multiplying the fetch traffic behind it. The read side scales with the write side, and both scale with the number of concurrent agents.

The compound effects show up in operational symptoms long before anyone draws an architecture diagram. Merge failures rise because ref updates queue behind fetch storms. CI waits lengthen because every job pays the pack-generation cost. Developers notice pushes taking seconds instead of milliseconds, and agents, which push far more often than any human, turn each of those seconds into a productivity tax multiplied across every parallel task. The reliability drop below 90 percent was not a blip; it was the point at which the serving layer became the constraint on the whole engineering organization.

Conventional Git serving handles this poorly for two structural reasons. First, most servers order every reference update repository-wide, so a push to one branch queues behind pushes to unrelated branches. Second, standard servers generate a fresh packfile for every client, computing a custom answer to every fetch. Under human traffic those costs hide. Under agent traffic they compound into the slowdowns and failed merges OpenAI was seeing.

The question behind Pando was which constraints were truly Git's, and which were serving-layer habits nobody had revisited. Two of them, it turned out, were habits.

The two assumptions Pando drops

Repository-wide consistency. A conventional server can show every branch at one coherent point in time, and that guarantee requires coordinating all writes through one order. Pando trades it away. Each branch is serialized on its own, and pushes to unrelated branches proceed fully in parallel. Clients conflict only when pushing the same reference at the same moment. The cost is honest and stated plainly: a reader looking at several branches may see them at different points in time. OpenAI's judgment, backed by production behavior, is that users and agents depend on the order of updates to a single branch, not on a global snapshot across all of them. The concrete example from the engineering post makes the relaxation easy to picture: if two branches move during the negotiation of a clone, one client may observe the first branch at version one and the second at version two, while another client sees the reverse. In a human-scale repository that window is invisible. In a monorepo with millions of branches and thousands of concurrent writers, the window is the price of making writes parallel, and OpenAI judged that its users and agents never actually relied on the guarantee being given up.

A unique packfile per client. Standard serving builds a custom pack per fetch, which is CPU-intensive precisely at the moment demand spikes. Pando stores each pushed pack as an immutable blob, records a reference version in scalable metadata, and reuses the same bytes for every reader. A push needs a constant number of metadata operations. A fetch needs a logarithmic number, based on how far behind the reader is.

Neither idea is exotic in distributed systems. What is notable is applying them to Git without breaking the client, which is where the cleverness lives.

Making packs small enough to share

Reusing packfiles is the idea that makes Pando scale, and it only works if the packs are generic, which requires controlling what the client excludes. The team's phrase for the conventional approach is a poker player showing all its cards: a server advertises every branch, the client builds a pack excluding anything it recognizes, and the resulting pack fits that client's history but nobody else's.

Pando shows fewer cards. With millions of branches, a full advertisement alone can exceed 100 MiB, so Pando advertises only trunk as the base for feature branch pushes. A client pushing a topic branch therefore builds a pack that depends only on trunk history, which any reader with that history can consume. The median pack in the monorepo came in under 20 KiB, and repeat pushes resend non-trunk history with a 99th-percentile pack under 3 MiB.

Fetches in Pando are served through packfile-uri, an existing Git protocol feature that lets the server hand the client download links instead of streaming bytes inline. A delivery layer called Express caches packs regionally with consistent hashing and reports hit rates above 99 percent, which is why clones and fetches saturate 10 Gbps links on ordinary cloud virtual machines.

Pando replaces garbage collection with compaction, in the pattern of log-structured merge trees. Each push creates a level-zero pack, background workers group packs into geometrically larger covers, currently up to level four, and the covers act as a skip list so pack selection runs in logarithmic time.

None of the pieces is a research breakthrough. The achievement is the composition: a Git-compatible server whose write path is metadata-only, whose read path is cache-friendly by construction, and whose consistency model is honest about what it relaxed.

What the numbers show, and what they do not

Every performance figure here is self-reported, and the distinction matters enough to repeat.

The reported Pando results: median push latency reduced by nearly 80 percent, roughly five times faster; close to a petabyte of Git data served per day on a handful of CPU cores; more than 57 TB of packs served in a single hour, over 99 percent from local disk cache; clones and fetches saturating 10 Gbps links on commodity virtual machines; and thousands of concurrent pushers working without degradation. The petabyte figure is the one that reframes the system, because serving that volume from a handful of cores is only possible when the servers negotiate and select packs rather than touching repository contents, which is the architectural payoff arriving in production numbers.

What supports Pando's claims beyond assertion is architecture and method. The write path is O(1) metadata work by construction, so the headline numbers are consistent with the design rather than magical. The team also published a 1,000-writer simulation comparing Pando against modeled three-phase-commit and write-ahead-log designs, while carefully labeling those teaching models, not benchmarks. And the deployment method, a read-and-write-through proxy, means traffic migrated without downtime, which is the kind of operational detail that suggests the numbers were produced under real load rather than in a demo.

What is missing for Pando is independent measurement. No third party has run this system, and the simulation is OpenAI's own model of competitors' designs. Readers should treat the numbers as a credible engineering account, not as a benchmark they can rely on for capacity planning.

Three labs, three bets on scaling source control

Pando did not appear in a vacuum, and putting it next to the alternatives clarifies what each system is really optimizing for.

The conventional design, which GitHub's production replication system uses, coordinates reference updates across replicas with a three-phase commit and a quorum. Every push pays for multi-round coordination, and every replica keeps a complete copy of the repository. The payoff is a strong guarantee: any replica can serve a consistent view of all references, and the same design serves roughly a billion repositories of mostly human-scale traffic. Under a monorepo's write load, the quorum round trips and replica disk saturation land directly on the push path.

A write-ahead-log design moves the coordination point into a shared manifest in blob storage. Packfiles upload in parallel, but every push updates the same manifest with a compare-and-swap, which caps how fast the repository can publish updates no matter how much blob capacity you add, and replicas fall behind when incoming writes outpace their indexing.

Pando takes a third path: per-branch serialization with causal consistency, immutable reusable packs, and caching that serves reads at line rate from commodity machines. Anthropic's system makes a different trade entirely, moving commits server-side, using its own client, and keeping no fully materialized repository copy, with a reported 200 times smaller CPU and memory footprint.

Three competent teams looked at the same problem, agent-era write load, and produced three different answers, disagreeing specifically about which guarantee users would miss. OpenAI bet that a global snapshot across branches is a guarantee nobody uses. Anthropic bet that the client itself is the thing to replace. GitHub bet that quorum coordination remains affordable at scale. Those bets are falsifiable, and the next two years of agent adoption will tell.

There is also a cautionary note in the divergence: none of the three systems is available to others in full. GitHub's infrastructure powers its service, Pando is internal, and the Anthropic system is internal. The ideas are spreading through engineering posts and upstream Git commits rather than through downloads, which means most teams will be adapting the concepts long before they can adopt any of the artifacts.

How it was built, and what that says about agent development

The construction story deserves as much attention as the architecture, because it is a worked example of agent-driven engineering at unusual scale.

One engineer designed the core; teams of Codex agents implemented it; production arrival took ten weeks. Quality came from tooling rather than review headcount: OpenAI wrote a Git conformance suite for agents, added deterministic simulation testing, and had agents using the current flagship model write formal specifications in Lean and TLA+ to surface bugs before runtime. A backend that coordinates millions of pushes was specified, not just tested.

The Pando deployment path matters too. It first ran as a proxy in front of the old system, so behavior could be compared under identical traffic before cutover. OpenAI also ships its own Git build to developer machines and the ChatGPT desktop app, which gave it control of the client side without forking the protocol.

The upstream story is the part other teams benefit from today, since Pando itself is not open source. Client fixes for concurrent, interrupted and resumed pack downloads, packfile-uri tracing, parallel pack indexing and explicit haves have gone or are going upstream, with the remainder tracked in a public patch tracker. This is the part of the story with immediate value for anyone running Git at scale, because those client improvements help regardless of what server sits behind them, and they arrived as contributions to Git itself rather than as a fork. The division of labor is deliberate: the parts of the system that everyone shares get fixed in the shared project, and the parts that only a hyperscale monorepo needs stay proprietary. The Pando backend stays internal, with the team saying it is exploring ways to share the technology.

What it means for everyone else

Most teams will never serve a petabyte a day, but agent multiplication is not unique to OpenAI, and Pando is the clearest public account of what that multiplication does to infrastructure. The pattern to watch is the ratio: when agents multiply pushes and each push multiplies fetches, repository traffic grows as the square of agent adoption, and serving layers designed for human pace hit walls at surprisingly modest team sizes.

The strategic lesson is also about where to spend effort. OpenAI kept the client, the protocol and the workflow, and rebuilt only the serving layer behind them. That is the same shape as other agent-era infrastructure decisions: keep interfaces stable, rebuild what is behind them, and let the consistency model bend where users will not notice. Teams weighing their own agent-driven infrastructure strain will find the same reasoning in persistent sandbox compute for agents, where session lifetime, not version control, was the constraint being rethought, and in the hardening steps that followed the LiteLLM supply chain attack, which showed what happens when a shared developer dependency fails under load.

There is also a competitive subtext. GitHub's own replication system uses three-phase commit with quorum, the exact design the Pando simulation shows saturating under write load, while Anthropic built a system with its own client. The three largest AI developers have now all rebuilt source control internals for agent traffic, each with a different bet on where compatibility should bend, and Pando is the only one of the three that kept both the client and the protocol untouched. Whose trade ages best is an open question, and for teams outside those walls, the practical takeaway is simpler: measure your own push-to-fetch latency, because it is now the metric that agent productivity quietly depends on. When the bottleneck appears, the fix will look less like buying bigger servers and more like asking which guarantees nobody actually uses, as the analysis in our AI gateway comparison showed for the serving layer above the repository.

For teams running coding agents against existing infrastructure today, the immediate checklist is unglamorous: instrument push and fetch latency at the 99th percentile, count fetches triggered per push, and watch for merge failures as the leading indicator. Those three numbers will tell you whether your monorepo is on the same curve OpenAI was on before Pando, and whether the interesting question is when, not whether, to revisit how your Git is served. The encouraging part of the story is that the first fixes cost nothing: several of the client-side improvements OpenAI shipped upstream help any team on any backend, and instrumenting your own latency requires an afternoon, not a rebuild.

Sources
Subscription Form