OpenAI Pando Explained: Scaling Git for Parallel Coding Agents

OpenAI described Pando on November 2, a Git-compatible backend serving its internal monorepo. The company reports nearly 80% lower median push latency and roughly a petabyte of Git data delivered daily. This is an engineering disclosure about an internal system, not a newly available Git hosting service.

How Pando handles parallel Git work

The technical explanation describes two choices. Writes to unrelated branches can proceed independently, and readers reuse stored packfiles instead of requiring a newly assembled download for each fetch. Packfiles bundle repository objects.

The trade-offs are explicit. Reading several branches does not guarantee one repository-wide snapshot. Reused packs can also transfer objects a client already has. OpenAI says Pando began serving production traffic in April, so November 2 marks publication of the architecture rather than its first deployment.

These internal measurements do not predict another company’s performance.

What is public and what remains internal

OpenAI has a public Git fork, separate from the Pando service. Its patch tracker documents work on parallel pack downloads, authentication, retry handling and reusing previously completed downloads. Entries distinguish changes in OpenAI’s build from other development branches and upstream contributions.

The tracker also exposes dates from before this announcement. These client changes should not all be described as software first released on November 2. The newly useful material is the explanation of how they fit a production architecture.

OpenAI says it is exploring ways to share Pando’s technology. The announcement does not establish public pricing or a customer launch date.

Why agent-heavy teams should care

When a coding task produces several candidate implementations, the shared cost is larger than the model calls alone. Each candidate can create a branch, trigger tests and request another copy of the repository. A workflow that feels cheap at one agent can become expensive when many agents repeat it together.

For a platform team, the practical question is where that repetition lands. Are workers waiting for Git data, package downloads, test capacity or review? Those are different bottlenecks, and a faster inference provider will not necessarily fix any of them.

The useful lesson is to measure the system around the agent. A team can start by tracking time from an agent’s completed edit to a testable commit, and separating transfer time from queueing and execution. That gives infrastructure work a concrete target instead of treating every delay as model latency.

Pando is an unusually large example, but the underlying question is relevant much earlier: when agents can generate work in parallel, can the rest of the engineering system accept it at the same pace?

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain infrastructure decisions and AI product launches in clear content that developers and founders want to read.

Book a 30-minute call.