A Git server falling over under agent load looks like a repo-size problem. OpenAI's Pando points somewhere else. It kept the monorepo and removed the coordination that made unrelated work wait in line.
OpenAI published "Scaling Git at OpenAI" on November 2. I read it through write-ups rather than the post itself, so the numbers below are OpenAI's, reported secondhand. The story: Codex let engineers run far more work in parallel, which meant more branches, pushes, merges and fetches, and the Git service buckled. Merge reliability at times fell below 90%, though Qodo reads that as supporting systems at their worst, not a steady rate. And the conclusion, per GBHackers, is the part that matters: the limit lay "in how it served the monorepo, not in Git itself."
What Actually Broke
Two things, and neither is the repo's size.
Unrelated work was ordered together. Per Qodo, pushes to unrelated branches had to wait on one another. A human team rarely feels that. A fleet of agents, each on its own branch, turns it into a queue.
Every branch costs every client. With millions of branches, the ref advertisement can exceed 100 MiB. Protocol v2 lets a fetch ask for just the refs it wants, but a push still gets the whole list. You can see the size of yours:
|
That prints your ref count and roughly the bytes it takes to list them, including every branch your agents left behind.
What Pando Changed
Pando keeps the Git protocol and the Git client, and replaces what's behind them. Each pushed pack is an immutable blob, and a ref version goes into a metadata store, so clients conflict only on the same ref. In Qodo's words: "two agents pushing to different branches never contend." Feature-branch pushes advertise only trunk by default, and regional pack caches absorb the reads, which matters when multiple automated jobs fetch identical commits after each submit.
Reported results: median push latency down about 80%, merge reliability at 99.99%, nearly a petabyte of Git data served a day. No write-up gives absolute latency numbers or a window for the reliability figure, so take them as direction.
Look at what they gave up to get there: no repo-wide point-in-time snapshot. Reads across branches can see different versions. That's the real trade. A global ordering was the thing everyone was waiting on, so they stopped promising one.
Monorepo, Still
None of the write-ups I read mention splitting the repo. They say all development moved to Pando without changing how engineers use Git. I've always been on the monorepo side: it was right for humans and it's very much right for AI, because an agent gets the whole system in one place and one change can cross a boundary atomically. The only good reasons to split are open source or organizational limits. Server load isn't one of them. That's a coordination bug, and splitting just moves it into your release process.
The same pattern will show up elsewhere. Anything that assumed a human's pace and serialized on a global thing, a merge queue, a shared CI runner pool, one lock in a deploy tool, gets found by agents first. Software is turning into manufacturing, and a factory finds its slowest station fast.
The Tradeoff
You are not OpenAI, and you shouldn't build this. A custom Git backend is a storage system you now own forever. Most teams need something much more boring:
- Delete merged agent branches on a schedule, because refs are a cost someone pays on every push.
- Watch push latency and merge failure rate as agent count grows, not just PR throughput.
- Cache fetches in CI, since your jobs are probably pulling the same commits over and over.
Pando also keeps the client on purpose. I think that's the right move for now, and my bet is it's a stop along the way: agents need primitives of their own, and a branch per task is still a human idea. Until then, the order of operations is the part worth stealing: fix the coordination first, and leave the repo alone.