OpenAI Pando Explained: How OpenAI Rebuilt Git for AI Agents (and Kept Every Command)

OpenAI says its AI agents were writing so much code that Git started breaking. Commits to its main branch were up 1,378%, and at the worst point more than one in ten merges failed. A month earlier, Anthropic hit the same wall and threw Git away.

OpenAI did the opposite. It kept Git, every command and every habit, and rebuilt everything underneath in 10 weeks, mostly with agents. It's called Pando. Below is how it works in plain English, the results, the pushback, and what it means for your own repo. We also ran our own test: 50 fake agents pushing to one Git repo at the same moment.

All Pando numbers here are quoted from OpenAI's post, "Scaling Git at OpenAI" by Aaron Friel, Taylor Blau and Ted Nyman (Nov 2, 2026). We are not affiliated with OpenAI, Anthropic or GitHub.

OpenAI hit the same wall as Anthropic

In October, Anthropic said AI was writing so much code that Git broke, so it built a replacement called Scion. We covered that in Part 1. Now OpenAI says the same thing happened to it: commits up nearly fifteen times, and merge reliability as low as 87.1%.

So who got it right: ditch Git, or keep it? By the end you'll know which one you'd pick for your own code.

Why Git breaks: our 50-agent test

Here's the problem in one picture. Imagine a notebook everyone in an office writes in. Before you add a line, you have to read the latest page. If someone wrote in it while you were reading, you start again. For a few people, that's fine. Now give every person ten AI agents.

We tested this on one laptop. One shared repo (a repo is the folder Git tracks), and a set of fake agents that each make one small change and push it at the same moment, then retry when Git says no, the way real agents do. We ran each setup three times.

With 50 agents on one branch, it took about thirty seconds to land fifty tiny changes, and the unluckiest agent had to try almost fifty times. This is one laptop, not OpenAI scale. Now picture it with many thousands of agents at once. That's what OpenAI says it was handling. Fetches and pushes got slow, merges failed, and reliability fell below ninety percent.

Ditch Git or keep it? Scion vs Pando

Anthropic's answer was: Git was built for people, so build something new for agents. It called that Scion, and left Git behind.

OpenAI's answer was: everyone already knows Git, and so do the agents. Don't make anybody change. Change the machine behind it. It called that Pando. Fittingly, Pando is also the name of a forest in Utah that looks like thousands of separate trees but is one living thing underneath. Thousands of branches, one root.

How Pando works: 3 ideas

1. Every branch gets its own mailbox

No more single notebook. An agent working on its own branch never waits for anybody else. The catch OpenAI admits to: if you look at two branches at once, you might see them at slightly different moments in time. It decided that's fine.

Our laptop test shows why this matters. Same fifty agents, but each one pushes to its own branch: zero rejections, done in under a second. That's about 45 times faster, from one idea: stop making everyone write in the same notebook.

OpenAI's own analogy helps here. A normal Git server is like a poker player showing all its cards, listing every branch it has before you can push. With millions of branches, that list alone can be over a hundred megabytes.

2. Don't unpack the parcel

When you push, Git bundles your changes into a small package (Git calls it a packfile). Normally the server unpacks and repacks it. Pando keeps your package as it is and hands that same package to whoever needs it next. Half of these packages are under twenty kilobytes.

3. Keep a copy close by

A local cache in each region answers more than 99% of requests without going back to the main store. In one hour, it served 57 terabytes.

OpenAI also put a simulator in the post. With a thousand writers at once, the shared-notebook designs took 56 and 96 seconds, and Pando took under eight. OpenAI labels these "synthetic teaching models, not production benchmarks", so treat them that way.

Built in 10 weeks, mostly by agents

This is the part that stands out. Ten weeks from kick-off to production. Designed by one engineer, built by teams of agents, deployed by a handful of people.

Even the move was done by agents: engineers asked Codex to migrate their setups. And because a bug in Git storage could quietly lose code, OpenAI had agents write mathematical proofs that the core rules can't be broken, in two different proof languages (Lean and TLA+).

Anthropic's Scion took a team of seven about five months. Two different labs, the same pattern: a tiny team plus agents rebuilt something most companies would never touch.

The results

The pushback

Not everyone is impressed. The biggest question on Hacker News was simple: what is all this code even doing? Fifteen times more commits, but is the product fifteen times better?

That's fair. More code isn't more value. One commenter who uses OpenAI's own model said it "writes code that appears to work", which isn't the same as sensible code. Others pointed out that the post gives growth only in percentages, with no absolute commit counts and no pushes-per-second benchmark.

The second objection: Google and Meta solved this years ago. True. What's new is who's doing the typing. Google built its system for tens of thousands of human engineers. These labs had to rebuild in months because agents showed up almost overnight. And it's not just them: Cursor, GitHub, GitLab and others have all published their own fixes this year.

Who's right, and 5 rules for your own repo

So: ditch Git or keep it? Anthropic went for a clean break and got a system built for agents from scratch. OpenAI kept every tool and habit working, and paid for it with one trade-off: branches can be a moment out of sync.

If you're a giant lab, either works. If you're everyone else, OpenAI's answer is the useful one. You don't need a new tool. You need to stop all your agents fighting over one branch. Here's what that looks like on your own repo:

1. One worktree (and branch) per agent. A worktree is a second working copy of the same repo, so each agent edits its own folder.
2. Let a merge queue land changes, not your agents. Agents hand finished work to a queue that merges it in order, instead of racing each other.
3. Small commits, so every package stays tiny.
4. Only check out the folders an agent needs (Git's sparse-checkout).
5. Turn on Git's file watcher (core.fsmonitor plus untrackedCache) so status checks stay fast on big repos.

Code is getting cheap enough that the hard part is no longer writing it. It's where it all goes, and whether any of it is worth keeping.

Get the free Agent Traffic Kit

We put all five rules, with the exact commands, plus our 50-agent test script so you can run it on your own machine, and Scion vs Pando on one page, into a free PDF. Comment PANDO on the video, or grab it below.