OpenAI has rebuilt the backend serving its monorepo to handle the parallel development workload created by Codex. The system, called Pando, now powers all development in that repository, according to the company’s November 2, 2026 technical announcement.
OpenAI reports nearly a fivefold reduction in median push latency and says Pando delivers nearly a petabyte of Git data daily. Engineers and agents keep using Git-compatible clients and protocols; the major changes sit behind that familiar interface.
Pando is an internal infrastructure system, with no public availability announced. Its useful contribution for other engineering teams is the design explanation: independent work on separate branches should encounter less shared coordination, while repeated downloads of shared history should reuse more server-side work.
Why Codex Put Pressure on Git Infrastructure
Codex increased the number of changes OpenAI engineers could develop simultaneously. More parallel changes meant more branches, pushes and merges. Each push could then trigger several CI jobs fetching the same commit, alongside downloads from development environments and research jobs.
That creates two distinct scaling problems:
- Write concurrency: Many agents push changes to different branches at once.
- Read amplification: Multiple consumers download overlapping repository history after those pushes.
OpenAI says its previous infrastructure experienced slow fetches and pushes, failed merges, and reliability that sometimes fell below 90%. The announcement does not define that reliability measure precisely enough to treat it as a general service-availability figure.
The distinction between read and write pressure matters. Adding download capacity will not necessarily fix coordination between writers. Making pushes faster will not eliminate repeated work preparing data for hundreds of readers.
My view is that this separation is the most transferable part of Pando’s design. Agent adoption can increase infrastructure activity without a matching increase in headcount, making developer count a less useful proxy for source-control demand.
Causal Consistency Lets Unrelated Branches Move Independently
Git stores repository content as immutable objects. Blobs contain file contents, trees describe directory structures, and commits connect snapshots to their history. Branches are mutable references, usually called refs, that point to commits.
Pando changes how the server coordinates those references. Updates to unrelated branches can proceed independently, while updates to the same branch still require coordination. OpenAI describes this as relaxing repository-wide consistency in favor of causal consistency.
Within the behavior described in the announcement, a reader fetching a branch receives the history needed for that revision. The server need not present every branch as part of one synchronized repository-wide snapshot.
OpenAI states the consequence plainly:
“The tradeoff is that a reader looking at several branches can see them at different points of time.”
That documented tradeoff is more important than the consistency label alone. Imagine an automation system reading a release branch and a feature branch while both are changing. It could observe the release branch before one update and the feature branch after another. Each branch can be usable independently, but their combined view is not guaranteed to represent one instant.
Independent branches gain concurrency; competing updates to one branch remain a coordination problem. Pando therefore fits workloads with many parallel branches particularly well. It cannot remove contention inherent in many writers targeting the same reference.
For release tooling that depends on a coordinated set of revisions, I’d favor recording explicit commit IDs in a manifest. That recommendation follows from the documented cross-branch limitation: repeatedly looking up moving branch names leaves the intended combination ambiguous. A manifest records the combination the workflow actually intends to use.
Reusable Packfiles Trade Extra Bytes for Less Computation
Git transfers objects in packfiles, which group objects and can compress similar content using deltas. During a fetch, the client communicates which commits it wants and which it already has. The server can use that information to prepare a tailored set of missing objects.
That tailoring saves network traffic, but it also creates server work. Many clients fetching similar history can cause the server to repeatedly calculate and package overlapping data.
Pando instead reuses stored packfiles across fetches. A client may receive objects it already possesses, but the server can distribute the same bytes repeatedly with little additional computation.
| Design choice | Benefit | Cost or condition |
|---|---|---|
| Independent branch coordination | Unrelated pushes can progress concurrently | Cross-branch reads lack one synchronized snapshot |
| Reusable packfiles | Less per-client packaging work and better cache reuse | Clients may download duplicate objects |
| Git protocol compatibility | Existing workflows can continue | Compatibility alone does not guarantee identical performance across client setups |
These are architectural exchanges, not free optimizations. Pando accepts some redundant transfer to reduce repeated computation and make caching more effective. OpenAI describes both choices in its technical account.
How Cached Packs Reach Clients
MarkTechPost’s implementation summary, based on OpenAI’s disclosure, reports that Pando uses Git’s packfile-uri capability to provide download locations for packfiles. A delivery service called Express caches those packs regionally.
Reusable files make this separation useful: the Git service can determine what a client needs, while a cache-oriented delivery layer serves the bytes.
The same report describes background workers combining smaller packs into progressively larger groups, resembling log-structured merge-tree compaction. This gives the read path larger reusable units instead of forcing every fetch to retrieve a long sequence of tiny files.
There is another bandwidth tradeoff. MarkTechPost reports that Pando advertises trunk as the base for feature-branch pushes, which makes those packs reusable by clients that already have trunk history. Repeated pushes can resend non-trunk history.
I’d treat that choice as workload-dependent. Compact feature branches can make the extra transfer acceptable. Long-lived branches with substantial divergence could produce a different balance between saved server computation and additional network traffic.
What OpenAI’s Production Numbers Show
OpenAI’s headline measurements concern its own monorepo. They are company-reported results, without an independent benchmark in the supplied evidence.
| Reported result | Useful interpretation |
|---|---|
| Nearly 5× lower median push latency | The midpoint push became substantially faster |
| Nearly 1 petabyte of Git data delivered daily | The system supports a large aggregate read workload |
| More than 57 terabytes served in one hour, with over 99% from local disk cache | Cached pack delivery handled a high-volume period |
| Clone and fetch operations saturating 10 Gbps links on standard cloud VMs | The reported setup could make downloads network-bound |
The first two figures appear in OpenAI’s announcement. The additional delivery figures are described in MarkTechPost’s account.
A fivefold latency reduction corresponds approximately to an 80% reduction in elapsed time. That describes the median, so it says little by itself about the slowest pushes or individual repository operations.
Frequently Asked Questions
3 questions
1Is Pando publicly available?
OpenAI has described Pando as its internal Git backend. The announcement does not offer public access or announce a public product.
