Codex broke OpenAI's Git server first, so OpenAI rebuilt it: meet Pando

Codex turned one person's output into a team's, and the Git server felt it first

On November 2, 2026, OpenAI published an engineering post, "Scaling Git at OpenAI," describing Pando, the Git backend it rebuilt for its own monorepo. The motivation is stated plainly: over the past year, the size and demands on the monorepo grew at a "staggering pace," and the team needed to revamp source control to scale to the level of concurrent work that Codex makes possible. Pando now powers all development in OpenAI's monorepo, and the company says it cut median push latency by nearly 5x while delivering nearly a petabyte of Git data per day.

The story does not start with Git being broken, but with how Git gets used changing. Codex lets one engineer hold several changes ready for CI at once, and each push can set several jobs fetching the same commit; development environments, research jobs, and CI keep cloning and fetching. More branches, more pushes, more merges, more fetches — and at some point the old server architecture started showing slow fetches, slow pushes, and failed merges, with reliability at times falling below 90%. The team asked the key question: had they hit a limit of Git itself, or of how they served their monorepo? Their answer was the second.

That judgment shaped the whole project. Many companies at this scale replace Git with a custom version-control system, at the cost of making every tool, script, and agent relearn it. OpenAI did the opposite: keep the Git protocol and client, rebuild only the server side. The benefits, as the post explains, are that engineers' and agents' workflows do not change at all, existing tools keep working, and client improvements can flow back to the broader Git community. For a company pushing Codex hard, there is another calculation: models already know Git commands best, so replacing Git would mean dismantling the agent's most fluent tool.

Pando's two design goals follow from this. First, writes must scale horizontally, optimized for concurrent pushes to many branches. Second, read throughput must be high enough for clients to download data fast enough to saturate their available network bandwidth. What makes Pando distinctive is what it gave up to get there — two things most Git systems treat as requirements.

The first thing it gave up: a consistent snapshot of the whole repository

Most Git services maintain a global order across all references: what the repository looks like at a given moment should be the same for everyone. The price is that all branch updates queue through a single coordination point — even pushes to unrelated branches wait their turn. As write volume grows, that point becomes the bottleneck.

Pando coordinates each branch independently. Pushes to unrelated branches proceed in parallel, while updates to a single branch remain serializable, and a reader fetching a branch sees the history of the writer who produced it. The trade-off is that a reader looking at several branches at once may see them at different points in time: one client might see branch foo at version 1 and bar at version 2, while another sees the reverse. OpenAI states its judgment openly: users and agents actually depend on the order of updates to a single reference, not on a global ordering of all references.

Whether that judgment holds depends on how you work. For most teams it does: you care that main advances in order and that your feature branch was not moved unexpectedly, not that every branch combination represents one millisecond in time. But tools that treat a whole-repository snapshot as a correctness premise — some cross-branch release orchestration, some global audits — could trip over the relaxation. The lesson generalizes: consistency is not a binary property but a bundle of guarantees you can split apart, as long as you say clearly which guarantee you dropped and who is affected.

Technically, Pando implements this with causal consistency. Each time a branch moves, the system records a ref version in a metadata store — the new tip, the pack that supplied it, and any earlier ref versions that pack depends on. Fetching replays those ref versions to reconstruct the writer's view. On push, the only contended key is the ref pointer itself, guarded by an atomic compare-and-swap-like operation. Scaling write throughput then becomes straightforward: add Pando servers, metadata store units, or blob stores.

The second thing it gave up: a custom pack for every client

A Git pack bundles multiple objects for transfer. The conventional approach computes a custom pack per client from what the client already has (haves) and wants (wants). That minimizes bytes transferred, but every fetch costs CPU and disk I/O to compute — and as readers multiply, pack computation drags the server down.

Pando reuses stored packs instead. The pack a client sends on push is stored as an immutable blob, and later readers get those same stored packs selected for them, with no fresh computation. The cost is that a client may download some objects it already holds, wasting a little bandwidth; the gain is that the server barely computes per reader, and the same bytes can serve many clients. Pando leans on an underappreciated Git protocol feature, packfile-uri: the server returns an empty pack inline and links to the real packs for separate download.

One elegant detail sits in the push negotiation: the server advertises only a small set of branches to the client, by default a single designated trunk branch. Two reasons: with millions of branches, advertising everything can exceed 100 MiB on its own; and the fewer branches advertised, the fewer dependencies the client's pack carries, making it easier for the server to later prove a fetching client already has those dependencies. The cost is real too: engineers who push the same branch repeatedly, or stack one feature branch on another, resend everything outside the trunk. OpenAI reports its own numbers: the median pushed packfile was under 20 KiB, the 99th percentile under 3 MiB — a trade worth making for its workload.

The other half of the read path is caching. Pando's pack delivery service, Express, caches blob storage in each region with consistent-hash routing, at over 99% cache hit rates. OpenAI says that on ordinary cloud VMs, clones and fetches saturated 10 Gbps links, with more than 57 TB of Git packs served in a single hour, over 99% of those bytes from local disk cache. These are OpenAI's own production figures, with no third-party reproduction — but they show the shape of the shift: once packs are reusable, the read bottleneck moves from server compute to network bandwidth, and bandwidth is something money can buy.

Write path and compaction: keeping small packs from dragging the system down

Each push produces one small "L0" pack, and over a day a client catching up on trunk could need tens of thousands of them. Pando borrows log-structured merge-tree compaction: background workers merge packs into larger "covers" from L0 up to L4. Covers serve two purposes: better compression, and acting as a skip list over ref versions so pack selection takes logarithmic time in how far behind the client is.

Unlike many Git servers, Pando does not garbage-collect packs at each level — it keeps them all in service, since different clients lag by different amounts and each level serves a different lag best. The philosophy repeats: trade storage for computation. Disk is cheap; compute is expensive, especially when readers vastly outnumber writers.

The write path itself is thin. On push, Pando validates the incoming packfile while streaming it to blob storage, without unpacking it into a local repository, then records a new ref version and atomically moves the ref pointer in a multi-key transaction. OpenAI says the whole write takes a constant number of metadata reads and writes regardless of push size, and pack selection on fetch takes logarithmic metadata reads in the ref-version distance between what the client has and wants. Those complexity claims are the key to Pando's scaling story: writes do not get pricier as pushes get bigger, reads do not get pricier linearly as clients fall further behind.

Ten weeks, one designer, teams of agents implementing

The most quotable passage is how Pando was built: kickoff to production in just 10 weeks, the core designed by a single engineer, implemented by teams of agents, deployed by a handful of engineers, serving production traffic since April 2026. The implementation is greenfield Rust with no legacy dependencies. Validation included a conformance test suite against standard Git behavior, deterministic simulation testing to find race conditions in negotiation and pack planning, formal methods (Lean and TLA+ written with GPT-6 Astra) to formalize a "theory of Pando" and prove properties, and around-the-clock red-teaming with Daybreak-capable models.

The right reading is not "AI wrote a Git backend" but "AI did a large amount of implementation inside strong constraints." The constraints are the point: a conformance suite that catches regressions immediately, deterministic simulation that reproduces races, formal methods that prove rather than suggest. For vibe projects, the takeaway is practical: before letting agents write critical infrastructure, ask whether you have equivalent validation — without a test suite and a reproducible failure case, faster implementation is not worth trusting.

Deployment is equally worth studying. Pando first went live as a read- and write-through proxy in front of the existing system, both kept in sync, with traffic migrated system by system and no downtime. Pando's caching could also deduplicate and combine requests before proxying, keeping the old backend healthy during migration. Client migration happened in phases through an internal wrapper around the Git CLI, after OpenAI shipped its own public Git distribution to developer machines and inside the ChatGPT desktop app, and migrated hundreds of integrations depending on legacy APIs, webhooks, and repository downloads — with Codex itself helping, via skills for preparing existing checkouts and migrating environments. No big-bang switchover, no "everyone changes tools on Monday." That is what infrastructure upgrades should look like.

The contributions back to Git may travel further than Pando itself

Because Pando is built on the Git protocol and client, the team found bugs and performance opportunities in Git's own handling of reusable packs, and contributed fixes upstream: edge cases in concurrent downloads, cleanup after interrupted transfers, resuming completed downloads, validations when accepting an existing pack for a fetch, and tracing and byte counts for packfile-uri downloads and pack generation. Its public Git build can already download and index independent packs in parallel, and added "explicit haves" so a server can advertise a branch's current tip separately from the history a pushing client may omit.

In some ways this matters more than Pando itself: Pando is currently an internal system only — no source code, no self-hosted package, no public API or deployment guide, with OpenAI saying only that it is "exploring ways to share the technology." But the upstream client improvements will reach every Git user eventually. It is also a useful signal for readers: a company that only talks about its internal system, with nothing flowing back to the commons, is offering experience you probably cannot reuse; a team that pushes improvements upstream usually writes posts worth reading closely.

Discount the numbers, keep the lessons

Run the official numbers once more: median push latency down nearly 5x (elsewhere stated as nearly 80%), nearly a petabyte of Git data per day, over 57 TB in a single hour, over 99% cache hits, merge reliability recovered from below 90%. All of it is OpenAI describing its own system: no baseline for the old backend, no hardware specification for the "handful of CPU cores," no error bars, and the three-way consistency simulation is explicitly labeled a synthetic teaching model, not a production benchmark. So the numbers only hold "in OpenAI's monorepo, on its workload" — they do not transfer directly into your team's expected gains.

Three lessons transfer without discount, though. First, redo the infrastructure math for the agent era: one person plus several agent sessions behaves like a small team, multiplying branches, pushes, fetches, and CI load; your Git host, CI runners, and artifact storage will hit their bottlenecks sooner than you expect. Watch three metrics now: push latency, merge failure rate, and fetch time per clone.

Second, a stable interface matters more than a fashionable backend. Pando's biggest product decision was not causal consistency or pack reuse, but "do not change the interface." The same applies to vibe projects: build agent toolchains, scripts, and CI configuration on stable public interfaces, not on one agent tool's private format. Stable interfaces keep the cost of switching backends, models, or tools low; a locked-in interface turns every upgrade into a migration.

Third, the validation system decides how far agents can go. Pando dared to use agents for its core because of three nets: a test suite, deterministic simulation, and formal methods. Your project may not need TLA+, but it needs at minimum: tests that agent changes must pass, a minimal reproducible case when things fail, and a one-click rollback for deployments. Without those three, the faster agents write, the closer you get to a production incident.

A checklist for small teams

If you want to judge how close your infrastructure is to the problem Pando describes, without waiting for any new product, run through this list. First, in the past month, has your repository seen noticeably slower pushes, unexplained merge failures, or CI repeatedly timing out fetching the same commit? If so, note the frequency and timing — that is the earliest signal. Second, count how many CI fetches re-download the same commit: agent sessions, cloud dev environments, and parallel jobs all manufacture repeat fetches, and a high repeat rate means your read path deserves attention. Third, check your branch hygiene: stale branches that are never deleted raise advertisement and negotiation costs, and regular branch cleanup is the cheapest performance optimization there is.

Fourth, run a thought experiment: if every team member opened three agent sessions tomorrow, which would hit its limit first — your CI concurrency cap, your Git host's rate limits, or your artifact storage bandwidth? The exercise costs nothing and exposes the weakest link in advance. Many teams doing this math for the first time discover the bottleneck is not code hosting at all, but something overlooked, like self-hosted runner disk speed or a script that clones in full every time. Pando's story boils down to one sentence: agents turned a "people" scaling problem into an infrastructure scaling problem, earlier than expected.

Finally, back to Pando itself: it is not something you can download today, and OpenAI has given no timeline or price for offering it. The value of the post is not "wait for a product," but that it writes out the exam paper for agent-era infrastructure in advance: when the people writing code go from one person to one person plus a group of agents, will your version control, CI, and storage hold up? OpenAI spent 10 weeks writing its own answer; yours can start with watching those three metrics.