Pando: How OpenAI Rebuilt Git for an Agent-Era Monorepo

A thicker backend, the same Git habits

We built Pando, a new Git backend for our monorepo, to handle more pushes and fetches without changing how our engineers and agents use Git.

OpenAI Developers, the developer-facing voice for Codex and the OpenAI Platform, introduced Pando on November 3, 2026. The write-up lives on developers.openai.com. Pando is a Git backend for OpenAI's monorepo: the layer that has to accept more pushes and serve more fetches as both people and agents hit the same repository.

The design bet is narrow and practical. Commands, daily habits, and the way engineers and agents talk to Git stay in place. Capacity moves to the backend. That is the whole product story in the announcement: more traffic on the paths teams already use, absorbed where the repository is served.

• Who it is for

  OpenAI engineers and agents working in the company monorepo, in a period when agent usage is rising alongside human work.

• What stays familiar

  How those engineers and agents use Git. Pando is built so that extra pushes and fetches do not require a new client workflow.

• What changes underneath

  The backend that has to keep up with that traffic, so Git capacity can grow alongside agent usage.

Why the monorepo feels the agent wave first

Agent work does not need a new Git dialect to stress a monorepo. The same repository still receives pushes and still answers fetches. What changes is how often those operations arrive. Codex-era agents add traffic on top of the human cadence, and the repository has to answer both.

OpenAI's framing is that this pressure shows up in Git before it shows up as a new developer ritual. If every extra agent meant a new tool, a new remote, or a new set of commands, the monorepo would fracture just as automation increased. Pando is the opposite move: keep the repository contract, and scale the service behind it so capacity can grow with agent usage.

What you can use from the announcement

Pando is described as infrastructure OpenAI built for its own monorepo. The public note does not ship an install, a config file, a protocol spec, or a migration guide for outside repositories. If you are looking for a drop-in Git server to clone this afternoon, that is outside what OpenAI Developers published. The official page is the announcement itself, on developers.openai.com.

The transferable part is the workload shape. When agents and people share one monorepo, push and fetch volume can jump while the useful interface stays ordinary Git. OpenAI's measured outcome on that shape is about 80% lower push latency and nearly a petabyte of Git data a day, with headroom framed as something the backend can add as agent usage grows. Treat those figures as OpenAI's results on OpenAI's repository, reported by the team that built the system.

• Same remote, heavier traffic

  A concrete internal workflow is unchanged Git from engineers and agents, pointed at the same monorepo, with Pando taking the extra pushes and fetches.

• Scale on the service side

  The stated goal is to grow Git capacity in step with agent usage, so the repository remains usable as automated work increases.

• Limits of the public note

  Architecture, hardware, and any comparison with other Git servers are not part of the announcement, so those details stay unknown from this write-up alone.