OpenAI makes Git pushes nearly five times faster with Pando

An agent has finished a change, but the tests have yet to start: first, the changes need to be pushed and the code downloaded into the test environment. With dozens of tasks running in parallel, waiting for Git can eat into the gains from rapid code generation. Pando's story is useful for teams adding more agents and trying to understand where the next queue will form.

What OpenAI reported

In a technical breakdown published on November 2, OpenAI described Pando, its internal Git backend. The company reports reducing median push latency by nearly a factor of five and serving almost a petabyte of Git data per day. Compatibility with the Git client and protocol has been preserved.

Two design choices underpin the system: independent updates to different branches and the reuse of prepared data packs for reads. However, reading multiple branches does not guarantee a single snapshot of the entire repository at one point in time. Pando runs internally at OpenAI; the company is considering ways to share the technology but has provided no release timeline.

For teams putting this into practice, the scope of the measurement matters. Median push latency describes the typical delay for a single operation. It cannot tell you how much faster a team ships its product. Tests, reviews, fixes and approvals still stand between pushing changes and a release. Making this stage nearly five times faster does not, on its own, promise the same speedup in development.

Example: agents prepare several changes

Imagine an online store's development team. One agent changes search, another fixes the shopping cart, and a third updates dependencies. Each works on its own branch. Once changes are pushed, the testing system needs to retrieve the right version of the code and run the tests. If checks start simultaneously, several readers access the same repository history.

Separating work by branch allows these operations to be handled independently. A search change does not have to wait for a cart update simply because both live in the same repository. Serving a prepared pack repeatedly is like sending the same archive to several recipients: the server benefits from reusing data it has already prepared. This is a simplified illustration of Pando's two principles, rather than a description of a particular store's infrastructure.

But another queue remains: the changes still need to be combined. If two agents modify the same section of code, a fast server will not decide for the team which version to accept. That requires rules for task ownership, conflict checks and a clear merge procedure. Storage performance and the quality of collaboration should be measured separately.

There is also an implication for automation. If a process makes decisions across several branches, the versions it compares must be explicitly defined. For example, a check that tests whether two changes are compatible should pin specific commits. Otherwise, a rerun may test a different combination of code, making the result difficult for a developer to reproduce.

What to check in your own workflow

Start by timing one complete task, from a finished change to the test result. Break the time down into pushing changes, retrieving code, waiting for an available runner and running the tests themselves. This breakdown will reveal which stage is actually slowing the work down. If most of the delay comes from the test queue, replacing the Git server will have a limited effect.

Then repeat the measurement at normal and peak levels of parallelism. What matters to the team is the point at which additional agents stop reducing task completion times. Look at both typical latency and occasional long waits: the latter can hold up an urgent fix. Compare results using the same tasks and the same number of checks.

These data will help product managers and founders assess the cost of speeding things up. An additional agent delivers value when its output makes it all the way through to an accepted change. If only the number of branches and unfinished checks is growing, address the queue first. The practical takeaway from Pando is to include Git and code delivery when measuring the productivity of agent-driven development. Decisions about new infrastructure should then be based on your own measurements.