The bottleneck was not the model
The scaling story in OpenAI's November 2 engineering post is not about inference. It is about version control. Codex let OpenAI's engineers run more changes in parallel, and parallel changes mean more branches, more pushes, more merges, and more fetches and clones from development environments, research jobs and CI. Each push can set several jobs fetching the same commit, so the demands compound. Starting around the end of last year, OpenAI says, the systems serving its monorepo fell behind: slow fetches, slow pushes, failed merges, and reliability at times below 90%.
The response was not a bigger server. OpenAI rebuilt the backend and kept the surface exactly as it was. Pando speaks the Git protocol and works with the Git client, so engineers and agents type the same commands they always did. Underneath, almost every assumption a conventional Git service makes has been traded away.
What Pando gives up to go faster
Two trades do most of the work. The first is consistency. In a globally coordinated design, updates across a repository can require coordination even when they affect unrelated branches. A push to one branch can therefore wait on activity elsewhere. Pando coordinates each branch independently, under what OpenAI calls causal consistency: updates to one branch stay in order and serializable, but a client reading several branches cannot assume those reads describe a single moment across the repository. OpenAI's judgment, stated plainly in the post, is that users and agents depend on the order of updates to a single reference, not on a global ordering of all of them.
The second trade is on reads. In the serving design OpenAI describes replacing, the server builds a packfile for each client based on what that client already has and what it needs. Pando instead reuses packfiles received on pushes, selects the stored packs a fetch needs, and hands the client links to download them through a caching service called Express. Clients may download some objects they already hold. In exchange, the server does little computation per reader, and OpenAI says clone and fetch operations saturated 10 Gbps links in tests on standard cloud virtual machines.
The details show why the conventional path broke. With millions of branches, merely advertising every branch to a pushing client can exceed 100 MiB. Pando advertises a designated trunk branch by default, accepting larger repeat pushes on stacked branches as the cost. In OpenAI's monorepo, the median packfile produced this way was under 20 KiB, and the 99th percentile was under 3 MiB. Per-push packs are then merged in the background into larger covers, up to a level OpenAI calls L4 today, so a client catching up on trunk does not have to download tens of thousands of individual packfiles each day.
Built by the thing it serves
Pando was itself an agent workload. OpenAI says it moved from kick-off to production in 10 weeks: the core designed by a single engineer, implemented by teams of agents, deployed by a handful of engineers, in Rust, as a greenfield system. It has served production traffic since April 2026. The validation story is part of the claim. OpenAI wrote a conformance suite against standard Git behavior and deterministic simulation harnesses to hunt race conditions, and it says agents using GPT-6 Astra wrote Lean and TLA+ formalizations of the design to find and fix bugs, in continuous sessions running for hundreds of hours, while other agents red-teamed Git and Pando around the clock.
Read that as OpenAI describing its own process, not as an audited account of how the system was built. The same caution applies to the comparison with the alternatives. OpenAI modeled two conventional patterns, three-phase commit and a shared write-ahead log, and reports that in its simulation of 1,000 clients pushing to distinct branches, the first showed far greater write latency under load and the second far greater read latency. Those are OpenAI's models of other designs, run by OpenAI, next to measurements of its own system in its own repository.
The numbers, with their limits
The production figures are concrete and worth stating exactly as OpenAI states them. OpenAI reports that median Git push latency fell to roughly one-fifth of its previous level, a reduction of nearly 80%. The post phrases that single improvement two ways — nearly 5x in its introduction, nearly 80% in its deployment section — and they are one improvement in two forms, not two gains. Pando delivers nearly a petabyte of Git data per day, has served more than 57 terabytes of Git packs in a single hour, and served more than 99% of those bytes from local disk cache. Merge reliability improved, OpenAI says, from a system that at times fell below 90%.
What the post does not give is just as specific. There are no absolute push times, before or after, so nobody outside OpenAI can say whether a median push now takes two seconds or twenty. There is no figure for merge reliability after the switch in the post's text, whatever secondary coverage has added. And there is one workload behind every number: a single, very large monorepo, operated by the company that built the system. A team with a different repository shape has no basis in this post for expecting the same multiples.
What anyone else actually gets
For now, the direct answer is nothing. Pando is internal. OpenAI says it is exploring other uses inside the company, including shared repositories for large numbers of collaborating agents, and that it is "currently exploring ways to share the technology that makes Pando possible with our users". No date, product name or price accompanies that sentence, and the post's own history counsels patience: Pando carried production traffic for roughly half a year before OpenAI described it in public.
The part outsiders can use today arrived by a different route. Building on the Git client surfaced real bugs in concurrent downloads, interrupted transfers and pack handling, and OpenAI says several of those fixes are already in upstream Git, with more in its public Git build and patch tracker, including parallel download and indexing of independent packs. That is a modest, checkable transfer, and it is currently the whole of what Pando means for anyone who does not work at OpenAI. The larger lesson travels without the software: when agents multiply the writers, the constraint moves from generating code to coordinating it, and at least one frontier lab has decided that constraint is worth rebuilding foundational infrastructure to remove.
Sources
- [1] OpenAI, "Scaling Git at OpenAI", November 2, 2026 (read first-hand in full before publication — the below-90% reliability and failed merges on the previous system; Pando's two goals and Git protocol/client compatibility; causal consistency and per-branch coordination, including the multi-branch point-in-time trade; packfile reuse, Express regional caches with over 99% hit rates and 10 Gbps saturation tests on standard cloud virtual machines; trunk-only advertisement, the 100 MiB full-advertisement figure, median pack under 20 KiB and 99th percentile under 3 MiB; L0-to-L4 background compaction and tens of thousands of packfiles a day; the 3PC and WAL comparison and the 1,000-client simulation; the 10-week build, single-engineer core design, agent implementation teams, Rust greenfield build with no legacy dependencies, conformance and deterministic simulation testing, GPT-6 Astra agents writing Lean and TLA+ formalizations, hundreds of hours of continuous sessions and around-the-clock red-teaming; production traffic from April 2026; median push latency reduced by nearly 80%; nearly a petabyte of Git data a day; over 57 TB in one hour with over 99% of those bytes from local disk cache; upstream Git contributions, the public Git build and patch tracker; "currently exploring ways to share the technology that makes Pando possible with our users", with no date)Read source
- [2] OpenAI Developers (@OpenAIDevs) on X, November 3, 2026, as quoted in Interesting Engineering's same-day report (read before publication — "We built Pando, a new Git backend for our monorepo… Pando cut push latency by ~80% and now serves nearly a petabyte of Git data a day") — used only for the November 3 amplification timing, not for any figure, since every figure traces to the post aboveRead source