OpenAI Details Pando, a Git Backend Built for Parallel Coding Agents

OpenAI has detailed Pando, a Git-compatible backend designed to serve parallel coding-agent workloads. Its engineering report was published on 2 November 2026; the company says production traffic began in April. This is a disclosure about existing infrastructure, not a new public product launch.

The report makes source control part of the agent-scaling discussion. Faster code generation is only one stage of getting a change accepted, tested and safely integrated.

What OpenAI says changed

In its primary engineering report, OpenAI says Pando now powers development in its monorepo, reduced median push latency by nearly 80% and serves almost a petabyte of Git data daily. These are company-reported production figures, not independently reproduced benchmarks.

OpenAI says one engineer designed the core and agent teams helped implement it. That is not a claim that the system was built or deployed without human engineering work.

The architecture trades a global snapshot for parallel work

Pando handles updates to independent branches separately and reuses compressed Git packfiles across downloads. Multiple branches read during one operation need not reflect a single point in time. The trade-off is part of its consistency model, not evidence of corrupted commits.

For a team evaluating a similar design, the useful distinction is between an immutable commit and a moving branch name. An integration test should record the exact revisions it used. A label such as “latest” is a poor substitute when several contributors are changing related components.

Consider a hypothetical pair of agents updating a shared interface and its consumer on different branches. A reviewer needs to know which versions were tested together, not merely whether both branches can be fetched quickly. That example illustrates an evaluation question; it is not a failure observed in Pando.

The public Git fork is not Pando itself

OpenAI’s Git fork is publicly accessible, but it is not a public release of the Pando backend. The company says it is exploring ways to share the underlying technology. General availability has not been established.

This limits what an outside team can reproduce. Testing a public Git build can establish how that build behaves in a specified environment. It cannot, by itself, validate performance claims about an unavailable server backend or recreate OpenAI’s production workload.

Measure accepted changes rather than agent activity

AgentsCalling’s analysis is that extra parallelism is valuable only if the rest of the delivery process can use it. A team could make pushes faster while spending more time waiting for tests, resolving overlapping changes or reviewing work that will never be merged.

The important measurement is therefore broader than commits per hour. Teams should compare how long it takes a proposed change to become an accepted, tested result, including retries and human review. Failed or abandoned changes belong in that calculation too.

Our coverage of GPT-6.1 Terra and coding-agent workflow costs looks at the model side of this question. Pando raises a separate assessment question: can the infrastructure keep pace when more work happens at once?

A practical test for parallel coding workflows

A useful experiment would start with a disposable repository and synthetic changes. Keep the repository, client machines and test workload fixed, then gradually increase the number of concurrent agent branches. Use separate runs for independent changes and changes that intentionally overlap.

Record push-to-fetch latency, push-to-CI latency, rejected updates, retries, network traffic and the number of changes ultimately accepted. Track typical and slow-tail results rather than reporting only the fastest run.

For cross-branch tests, record each fetched commit ID and the exact combination passed to CI. That makes it possible to distinguish a transport delay from a test using mismatched revisions. Include human integration effort so a faster push is not mistaken for a faster delivery cycle.

These are proposed tests, not results from an AgentsCalling evaluation. Without access to Pando, they would evaluate the available tooling and the team’s own workflow, not reproduce OpenAI’s backend benchmarks.

The central question is not whether more agents can generate more changes. It is whether the whole system can turn those changes into reliable, reviewable software without simply moving the queue somewhere else.

Prepared with AI-assisted research and drafting. Dates, architecture and performance claims were checked against OpenAI’s engineering report. AgentsCalling has not independently benchmarked Pando.