Pando: When AI Agents Force Git Infrastructure to Scale

A coding agent does not only produce code. It also creates branches, pushes commits, triggers CI and fetches history. Give a team several agents working in parallel and a quiet part of the development stack suddenly has a much louder workload.

On November 2, OpenAI described Pando, a new Git backend for its monorepo. The company says Pando now serves all development in that repository while preserving compatibility with the Git protocol and client. OpenAI reports that, in its production environment, median push latency fell by nearly five times and the service delivers nearly a petabyte of Git data per day. Those are OpenAI’s reported results for its own workload, not a benchmark for every team.

The interesting lesson for me is the choice of boundary. OpenAI did not ask every engineer and agent to abandon Git. It changed how the repository is served.

Two kinds of pressure

Git stores a repository’s history as objects: blobs contain file contents, trees describe directories, and commits point to snapshots and parents. Branches are references, or refs, that point to commits.

A busy backend must handle writers pushing updates and readers fetching history. If every independent branch update must wait for a single repository-wide ordering step, parallel agents can end up queuing behind work that has no relationship to their own branch. At the same time, generating a custom packfile for every reader can consume server CPU and storage bandwidth.

Pando addresses those pressures with two linked choices:

1. Coordinate each ref independently. Pushes to different branches can proceed concurrently. Competing updates to the same ref still need coordination.
2. Reuse stored packfiles across readers. A client may receive objects it already has, but the backend can serve the same bytes to many clients instead of computing a unique response every time.

These are architectural choices, not a claim that every Git server should work this way. Whether they help depends on the workload and the consistency guarantees a team actually needs.

Faster concurrency has a consistency tradeoff

The important detail is what Pando does not promise: a reader looking at several refs cannot assume they all reflect one repository-wide point in time. OpenAI describes this as causal consistency across the repository while preserving serializable updates to each individual ref. The history required to fetch a ref must be available, but two independently updated branches can appear at different moments.

That distinction matters if tooling compares several branches as if it had taken one atomic snapshot. I would first ask what such a tool relies on, and test its assumptions before changing the storage model. A faster push is useful; a misunderstood consistency model can produce a harder debugging problem later.

What an engineering team can take away

Most teams do not need to build Pando. They can still learn from the questions behind it:

• Measure both sides. Separate push latency, fetch latency and failure rate before deciding where the bottleneck is.
• Trace fan-out. One push may cause multiple CI jobs and agents to fetch the same history. Count readers as well as writers.
• Document consistency assumptions. Identify automation that relies on a single view across branches, and test it explicitly.
• Keep protocols and interfaces in view. OpenAI chose Git compatibility; that let existing clients continue to participate while the backend changed.
• Treat company numbers as context. Reproduce relevant measurements against your own repository and infrastructure before predicting an improvement.

OpenAI also describes a public distribution of Git and says it plans to contribute client improvements upstream. Its public Git repository is separate from the Pando backend described in the article; the report does not establish that Pando itself has been released as open source.

More agents can multiply the number of changes in flight. The engineering challenge is to make those changes cheap to share without losing sight of what each reader is actually guaranteed to see.

Sources

• OpenAI: Scaling Git at OpenAI, November 2, 2026.
• OpenAI’s Git distribution.
• Thumbnail uses the original Git logo by Jason Long, licensed CC BY 3.0, from the Git Project’s official logo page. The Git logo identifies the Git software and protocol; it does not imply endorsement.

Sources reviewed November 9, 2026. Follow jpalanco.com for more notes on AI, engineering and open-source tools.