As AI agents such as Codex become deeply embedded in software development, OpenAI's conventional source code management infrastructure hit its capacity limits. The problem was not Git's data model itself but the server-side machinery that handles massive numbers of parallel operations. On November 2, 2026, OpenAI published technical details of Pando, a new backend for Git repositories built to solve these problems, on its official engineering blog.
According to OpenAI, Pando maintains compatibility with the existing Git protocol and clients while supporting all development work in the company's large monorepo. Since its introduction, the median time for push operations has dropped by about 80% compared with the previous system, cutting it to roughly one-fifth. However, OpenAI has not disclosed the absolute push times before and after the migration. This does not mean processing speed improved by 80%; it means the time it takes for a push to complete fell by about 80%.
The background is a surge in development work driven by the spread of AI agents. At OpenAI today, a single engineer uses Codex to advance multiple changes in parallel, committing and pushing repeatedly on each branch. In addition, continuous integration (CI) and research jobs run large numbers of clones and fetches at the same time to retrieve the same commits. As these demands piled up, push and fetch delays became routine on the previous Git backend. Rather than replacing Git itself, OpenAI redesigned the internal structure of the server that handles the protocol, solving the problem while keeping the existing development environment intact.
データを表で見る
| プッシュ所要時間 (相対遅延（旧システム=100）) | |
|---|---|
| 移行前（旧システム） | 100 |
| Pando導入後 | 20 |
If the median push latency before migration is set at 100, it fell to about 20 after Pando was introduced. The improvement comes from a design that fundamentally reworks server-side synchronization and data delivery without changing Git's basic data structures.
Parallel work by AI agents exposed the limits of Git servers
According to OpenAI, the source code management infrastructure that supported its monorepo began to struggle with a rapidly growing load around late 2025. Not only did fetch and push speeds slow, but branch merge failures also became frequent, and a reliability metric temporarily fell below 90%. When engineers using Codex submitted multiple changes to CI at once, each push triggered several test jobs, and requests to retrieve the same commits concentrated on the server. A load that rarely caused problems in the era dominated by human developers surfaced because of parallel work by AI agents.
Running a Git repository in a distributed environment requires managing both the objects that store source code and history, and the references (refs) that indicate things like branch tips. When multiple servers handle the same repository, the Git objects reachable from a ref must be available before that ref is updated. And when multiple clients try to update the same branch at once, conflicts must be handled properly. Traditional distributed Git systems have ensured this consistency by coordinating the order of updates across the whole repository.
In designing Pando, OpenAI compared two representative traditional architectures: three-phase commit (3PC) and a shared log.
In the three-phase commit approach, multiple replicas each hold a complete copy of the repository, and ref updates are coordinated among them. In the configuration OpenAI modeled, the server that receives a push sends the packfile to each replica and finalizes the operation only after confirming that a majority of replicas accept the update. This approach requires multiple rounds of communication and disk writes between replicas, so pushes take longer to complete. When write requests increase in particular, replica disk performance and network latency become bottlenecks.
The other approach, the shared log, manages update order using a write-ahead log (WAL) on object storage. After the pushed packfile is saved to storage, its location and the ref update are recorded in a shared manifest. Manifest updates use a compare-and-swap operation to confirm that they do not conflict with other writes. But even pushes to unrelated branches must update the same manifest, so conflicts arise when writes concentrate. Even if the storage's own throughput is increased, the mechanism of updating a single manifest remains a performance constraint.
The challenge common to both approaches is that the mechanism coordinating updates across the whole repository also limits parallel processing of independent branches. OpenAI therefore set two design goals for Pando: handling writes to unrelated branches independently, and efficiently delivering the same data to many clients.
Pando saves packfiles received from clients directly to object storage as immutable data, without unpacking them into a local repository on the server. A packfile is a file format that compresses multiple Git objects together. Pando validates incoming data as it streams and simultaneously records the new state of the ref in a metadata store. Each ref version includes the new tip of the branch, the corresponding packfile, and its dependencies on earlier ref versions.
When a push is finalized, Pando records the new ref version in the metadata store and atomically updates the pointer to that ref. This lets it detect conflicts when multiple clients try to update the same ref, while processing pushes to unrelated branches in parallel. According to OpenAI, the number of metadata reads and writes required for this synchronous update is held to a constant, O(1), regardless of push size. Note, however, that this refers to the number of metadata operations; it does not mean the entire push, including packfile transfer and validation, finishes in constant time regardless of data volume.
Read handling also differs greatly from a typical Git server. A typical Git server compares the commits the client has with the commits it wants, then builds a dedicated packfile containing only the missing objects. Pando instead reuses packfiles saved from past pushes. It selects the combination of packfiles that contains the data the client needs and returns their download locations using packfile-uri, a Git protocol feature.
Actual data transfer uses a regionally deployed caching service called "Express." The client uses the URIs received from the Pando server to fetch the stored packfiles through Express. Because the server does not need to generate a packfile for each client, CPU and disk I/O load stays low even when the same data is delivered to many clients. According to OpenAI, the number of metadata lookups needed to select the required packs is O(log Δ), where Δ is the shortest distance in ref versions between the state the client holds and the state it wants to fetch.
To tidy up the packfiles that accumulate over time, Pando also uses a mechanism similar to compaction in log-structured merge trees (LSM trees). The smallest unit of packfile produced by each push is called L0, and background processing progressively merges them into larger groups (covers) that span multiple ref versions. OpenAI's monorepo currently uses covers up to L4. This hierarchy not only improves transfer efficiency through repacking but also serves to traverse ref history like a skip list. Because the required packs can be narrowed down in logarithmic time, fetches are handled efficiently even in environments with huge numbers of accumulated commits.
Design decisions that relax strict repository-wide consistency
Pando's high parallelism comes from relaxing some guarantees that have been prized in traditional Git hosting. Most important is the adoption of causal consistency in place of guaranteeing repository-wide snapshot consistency. Pando preserves serializability of updates to each individual ref and also guarantees "read-your-own-writes," so a client can immediately read changes it has written. It does not, however, guarantee that all refs in a repository are observed as the state at a single point in time.
Consider two branches, foo and bar, being updated at the same time. When one client clones the repository, it may observe foo at version 1 and bar at version 2, while another client may see foo at version 2 and bar at version 1. This is because Pando does not guarantee aligning updates to different branches into a single repository-wide timeline. When fetching a specific branch, however, it ensures the history and dependencies behind that state can be reproduced.
OpenAI concluded that ordinary development work does not require knowing the strict update order of every branch in the repository. Both human developers and AI agents can proceed as long as they can track the update history and dependencies of the branches they work on. Prioritizing parallel processing while preserving per-branch consistency was a better fit for the company's development environment than coordinating every write to maintain repository-wide consistency.
Another key change is reducing the ref advertisement, the ref information the server presents to the client during a push. A conventional Git server shows the client the refs of the branches it holds, and the client uses that information to build a packfile that excludes objects already on the server. This keeps transferred data small, but in a monorepo with millions of branches, the ref advertisement alone can exceed 100 MiB. The work of managing and sending that much ref information is itself a burden on the server.
Pando therefore adopted an approach in which, for pushes to a new feature branch, it generally advertises only the tip of the baseline trunk branch. This keeps the amount of advertised ref information down even as the number of branches grows. It also narrows which history the client assumes when generating the packfile, making that pack easier to reuse when fetched by other clients. A client that already has the trunk history can in some cases obtain the feature branch's contents from a single packfile.
This approach can, however, increase duplicate data transfer. Pushing repeatedly to the same feature branch, or doing stacked development in which changes build on another feature branch, means repeatedly sending objects not contained in the trunk. In OpenAI's monorepo, packfiles for pushes generated this way had a median size under 20 KiB and a 99th percentile under 3 MiB. These are measurements from the company's own development environment, though, and other repositories will not necessarily fall within the same sizes.
Fetches and clones involve a similar trade-off. Because Pando reuses stored packfiles instead of extracting only the objects each client is missing, clients may download data they already have. In other words, it prioritizes reducing server-side compute load and disk I/O and serving quickly from cache over minimizing network transfer. OpenAI judged this design better for overall processing efficiency in its environment.
The characteristics of the approaches compared in OpenAI's technical announcement are summarized below. This is a comparison of architectures modeled by the company, not a benchmark measuring different real-world Git hosting products under the same conditions.
| Approach | Write coordination | Read mechanism | Main performance constraint | Design characteristics |
|---|---|---|---|---|
| Three-phase commit (3PC) | Refs updated through consensus among replicas | Served from each replica's local repository | Inter-replica communication latency and disk load | Keeps ref state consistent across replicas, but coordination load during updates is heavy |
| Shared log (WAL) | Update order fixed through compare-and-swap on a shared manifest | Replicas read the log, apply the data, and serve it | Manifest update conflicts and replica catch-up lag | Pack storage can be parallelized, but ref-update coordination is concentrated at one point |
| Pando (causal consistency) | Independent atomic updates per ref | Selection of stored packs and cached delivery via Express | Client bandwidth, network, and storage throughput | Relaxes repository-wide consistency and tolerates duplicate transfer to increase parallelism |
Pando's distinguishing feature is not simply that it speeds up Git processing, but that it rethinks what to guarantee and what to relax. It gives up aligning the strict update order of all branches and accepts some duplicate data being transferred between client and server. In return, it can process updates to unrelated branches independently and efficiently deliver the same history to many clients.
About 1 PB delivered per day, in production within 10 weeks
OpenAI has published several concrete figures on Pando in production. The company's monorepo currently delivers about 1 petabyte (PB) of Git data per day. At peak, it delivered more than 57 terabytes (TB) of Git packfiles in an hour, and over 99% of that traffic was served from local disk cache. By caching frequently fetched packfiles, it limits access to the underlying object storage even when a large volume of fetch requests arrives.
In testing on ordinary public cloud virtual machines, it also confirmed that clone and fetch operations could saturate 10 Gbps of network bandwidth. Because the Pando server is mainly responsible for Git protocol negotiation and packfile selection, the CPU resources needed for data delivery are small. OpenAI says a small number of CPU cores can support delivering about 1 PB of data per day. These are, however, results in the company's own environment as published by the company, not an independent third-party performance comparison.
The official OpenAI announcement also describes a simulation comparing the performance of Pando, three-phase commit, and the shared log. It evaluated, under conditions where 1,000 clients each pick a different branch and repeatedly push independent commits, the total processing time and the delay until a pushed change can be fetched by another client. The behavior of each approach was compared while varying virtual machine and storage performance, and the three-phase commit approach was also given relaxed repository-wide consistency requirements as a comparison condition.
In the simulation, as load increased, the three-phase commit approach became constrained by replica disk performance and write latency grew. The shared log approach, meanwhile, could not keep up with the work of servers reading data from the log and applying it, and read latency increased. Pando reportedly maintained high parallelism through independent per-branch updates and cache-based delivery. This is a model for verifying architectural characteristics, however, and does not include the build and automated test times that occur in real development.
Pando's development timeline is also notable. According to OpenAI, it took only 10 weeks from project start to production deployment. A single engineer designed the core architecture, and a team of AI agents handled most of the implementation work. A small number of engineers carried out deployment, and production traffic handling began in April 2026. In effect, infrastructure to cope with the growth in AI agent development work was built with help from AI agents themselves.
Rust was chosen as the implementation language. OpenAI says it developed Pando as a new codebase without inheriting old dependencies from the existing system. For verification, it created a test suite to check conformance with standard Git behavior, and used deterministic simulation testing to investigate race conditions lurking in protocol negotiation and packfile selection. Through this verification, it reportedly found and fixed subtle bugs and performance issues related to concurrency.
Multiple AI models were used in development, and "GPT-6 Astra" was used in later stages. According to OpenAI, AI agents formally described Pando's behavior using Lean and TLA+ and verified properties of the system, discovering and fixing implementation bugs. Agents also worked continuously for hundreds of hours, continuing to detect problems hidden in edge conditions. The company also ran continuous red-team testing of Git and Pando using Daybreak-compatible models. However, which properties were formally verified, and how far the correctness of the whole system was proven, cannot be determined from public information alone.
Migration to production also proceeded in stages. Initially, Pando was placed in front of the existing source code management system and operated as a proxy relaying read and write requests. Traffic was migrated without downtime while keeping the state of Pando and the legacy system synchronized. The company also used a feature that coalesces requests for the same data so the existing system was not overloaded during the migration.
The migration included not just the Git server but also many related systems, such as code review, change requests, webhooks, automation APIs, and repository download features. OpenAI migrated hundreds of integrations to the new foundation and distributed a Git client with its own improvements to developers' machines and the ChatGPT desktop app. It also prepared a skill for setting up existing checkouts so developers could ask Codex to handle the environment migration. After this work, Pando now supports the company's entire monorepo.
After migration, merge reliability improved and median push latency fell by about 80%. However, the company has not disclosed what percentage the reliability metric, which had at times fallen below 90%, recovered to after the migration. While the latency improvement is quantitatively confirmed, the stability of operations remains only a qualitative description from OpenAI.
Pando is not public; benefits for outside users hinge on improvements to Git itself
What Pando shows is that the performance demanded of source code management is changing as AI agents spread. In an environment where multiple agents create branches in parallel and repeatedly commit and push, far more read and write requests arise than in traditional operations designed around human developers. As a result, coordination of server-side ref updates and packfile generation can become performance constraints before Git's data structures themselves do. Pando is a new design example for coping with that load.
External development teams, however, cannot adopt Pando in their own infrastructure at this time. OpenAI has not released Pando's server implementation as open source, and has not announced when it might be offered as a managed service, its pricing, or plans to distribute a package for self-hosting. The company says only that it is considering ways to share the technology underpinning Pando with users. It is also still exploring internally the possibility of having many AI agents collaborate on a single repository.
Meanwhile, some of the Git client-side improvements gained through Pando's development have already been published. OpenAI has released its own Git repository and is proposing several improvements to standard Git. Particular emphasis is on speeding up and improving the reliability of data retrieval using packfile-uri. Work is under way on issues found while operating Pando, including parallel packfile downloads and indexing, post-processing when transfers are interrupted, and state checks on resume.
OpenAI's Git client can download multiple independent packfiles in parallel and build their indexes. It also introduces an "explicit haves" mechanism that distinguishes the branch tip information the server advertises during a push from the history the client may assume when generating a packfile. This lets it detect feature branch update conflicts with --force-with-lease while limiting the dependencies of the transferred packfile to trunk history. If other clients have the same trunk history, they can reuse that packfile to fetch the branch's contents.
Features for tracking packfile download time and transfer volume during generation have also been improved. This makes it easier to tell whether slow fetches stem from server-side packfile generation or network transfer. Such improvements may be useful in Git hosting environments other than Pando as well.
Not all of the improvements OpenAI has published have been merged into standard Git, however. For example, for the feature that fetches packfiles in parallel from multiple packfile-uri entries, a pull request to Git itself (PR #2262) was submitted. That PR was closed without being merged on September 30, 2026, and OpenAI commented that it intends to reopen it after rework. At present, this proposal cannot be treated as a feature available in standard Git.
Some of the fixes OpenAI developed have already been incorporated into Git itself. Through a public patch tracker, the company distinguishes between changes accepted upstream and improvements that remain only in its own build. In July 2026, fixes related to races in parallel downloads using packfile-uri and to file management after interrupted transfers were reflected in standard Git. Parallel indexing of independent packfiles, explicit haves, and others are still shown as features of OpenAI's own build. For them to become widely available, review and verification by the Git community and formal acceptance will be needed.
Pando's design is also not suited to every development environment. In systems that need to know the strictly identical point-in-time state of multiple branches, relaxing repository-wide snapshot consistency could become a problem. In environments with tightly constrained network bandwidth, an approach that tolerates transferring duplicate objects could even be disadvantageous. Pando's results need to be evaluated as the product of a design tailored to the load and operating conditions of OpenAI's monorepo.
For external development teams, what matters is not to take Pando's performance figures as targets for their own environments. The first step is to understand which Git server processes become bottlenecks when AI agents are introduced, and to revisit read/write parallelism and cache use as needed. The roughly 80% reduction in push latency that OpenAI has shown is a strong design example for handling large-scale AI agent development. Going forward, whether Pando's technology is made public, and how far the company's Git client improvements are incorporated into standard Git, will shape the impact on the broader developer community.