OpenAI rebuilt its Git backend for agent-scale work

Why coding agents changed the Git workload

OpenAI's November 2 engineering report [1] says Codex let engineers prepare several changes for CI at once. Each change created more branches, pushes, merges and repeated fetches from development environments, research jobs and CI.

OpenAI says its previous monorepo systems developed slow fetches and pushes, failed merges and reliability that sometimes fell below 90%.[1] The pressure came from concurrency rather than repository size alone: many writers updated different branches while many readers requested overlapping history.

This is a useful distinction for other teams. A larger repository can often be handled with partial clones, better indexes or faster storage. Agent fleets add a coordination problem because independent workers can publish and consume changes at the same time.

How Pando handles pushes

A conventional replicated Git service may coordinate updates across complete repository replicas, while a log-based design can serialize updates through one shared manifest. OpenAI argues that both approaches create a repository-wide coordination point even when two pushes target unrelated branches.[1]

Pando streams an incoming packfile to blob storage, validates it without unpacking it into a local repository and records a ref version in a horizontally scalable metadata store. A compare-and-swap-style update protects the branch pointer. Pushes to different refs can therefore proceed independently.[1]

Each ref version records the new tip, the pack that supplied it and earlier versions on which that pack depends. Updating one branch remains serializable, while the repository as a whole does not promise one point-in-time ordering for every ref.

How Pando makes fetches reusable

A normal Git server calculates which objects a client lacks and often builds a client-specific packfile. Pando instead selects previously stored packs that cover the requested commits. It returns their locations using Git's packfile-uri feature and sends an empty pack inline.[1][2]

OpenAI's Express service caches packs regionally. The report claims cache hit rates above 99%, 10 Gbps links saturated on standard cloud virtual machines and more than 57 terabytes of Git packs served in one hour, with over 99% of those bytes supplied from local disk cache.[1] These are vendor-reported production measurements.

Reusing packs can send a client some objects it already has. Pando accepts that bandwidth trade-off to reduce per-fetch computation and make the same bytes cacheable across many clients.

The consistency trade-off

Pando offers read-your-own-write behavior for a branch and serializes updates to each ref. It does not give every clone or fetch a single point-in-time snapshot of all branches.[1] One client could observe branch foo at version one and bar at version two while another sees the reverse combination.

OpenAI calls this causal consistency and says users and agents depend mainly on the order of changes within one ref. That assumption may fit isolated agent branches, but systems that coordinate releases by reading many refs together need to evaluate it carefully.

Git compatibility also has limits. OpenAI ships its own public Git distribution with parallel pack downloads and has contributed packfile-uri fixes upstream.[1][3] A familiar command-line interface does not mean every stock client or hosting architecture gets Pando's performance automatically.

What teams can apply now

• Measure branch creation, pushes, fetches, merge failures and CI fan-out separately from repository size.
• Give autonomous workers isolated branches or worktrees and make same-ref conflicts explicit.
• Cache immutable Git objects and avoid rebuilding identical transfer data for repeated CI consumers.
• Use partial clone, shallow fetch or sparse checkout only after measuring whether object transfer is the actual bottleneck.
• Test release tooling that reads several refs before adopting a weaker repository-wide consistency model.
• Keep conformance tests, deterministic simulations and rollback paths around source-control changes.

What remains uncertain

• OpenAI has not published Pando itself or a migration path for teams outside the company.[1]
• The performance figures come from OpenAI's workloads and have not been independently benchmarked.
• The report does not provide a full cost comparison with established Git hosts or alternative monorepo systems.
• Relaxed cross-ref consistency may be unsuitable for workflows that require an atomic view across many branches.
• Pando's results depend on OpenAI's modified Git client, metadata services, blob storage and regional cache layer working together.

Frequently asked questions

• Is Pando a replacement for Git? No. It is a backend that retains the Git protocol and client workflow.[1]
• Can developers download Pando? OpenAI says it is exploring ways to share the technology, but the backend is not currently released.[1]
• Why not add faster Git replicas? Complete replicas still coordinate writes and must ingest incoming packs before serving them. Pando separates ref metadata from immutable pack delivery.[1]
• Does Pando make every fetch smaller? No. Reusable packs may include objects the client already has, trading some bandwidth for cacheability and lower server computation.[1]
• What should a small team copy? Start with workload measurement, isolated agent branches, immutable-object caching and conformance tests rather than recreating Pando.