Three weeks ago I wrote about Anthropic replacing git because their agents outgrew it. Yesterday OpenAI published Scaling Git at OpenAI, by Aaron Friel, Taylor Blau and Ted Nyman. Same pressure, different answer.
I read it twice. It is one of the best pieces of systems writing I have seen this year, and the interactive simulations are worth your time. I also think it leaves the most interesting question for agent-heavy teams open. OpenAI seems to think so too: the last section lists many agents collaborating on one shared repository as something they are still exploring.
This post covers what Pando does, where it is far ahead of anything we have built, and the layer Nool works on, which Pando does not touch.
What happened at OpenAI
The chart near the top of the post tells most of the story. Commits landed on OpenAI's monorepo master branch were up 1,378% in Q3 2026 compared with Q1 2024, and the base case for Q4 is about 2,442%. Codex lets one engineer have several changes ready for CI at once, and every push sets several jobs fetching the same commit.
By the end of 2025 the old system was buckling: slow fetches, slow pushes, failed merges, and reliability that at times dropped below 90%.
They did not replace git. They kept the git client and protocol exactly as they were and rebuilt the server behind it. They called it Pando.
How Pando works, in plain words
Pando makes two bets.
Bet one: stop ordering the whole repository. Most git services put every ref update in one line, whether through a quorum of replicas (three-phase commit) or a shared log in blob storage. That line is fine until thousands of writers stand in it. Pando gives each branch its own line. A push is stored as an immutable packfile in blob storage, and the branch gets a new "ref version" in a metadata store. Two pushes conflict only when they hit the same branch at the same moment. The price is that a reader looking at several branches may see them at different points in time. OpenAI calls this causal consistency, and argues that users and agents "depend on the order of updates to a single reference," not on a global order.
Bet two: stop building a custom pack for every reader. A normal git server computes exactly which objects you are missing and compresses them just for you. That is expensive, and you cannot cache it. Pando hands out packfiles it already has, through git's little-known packfile-uri feature, from regional caches. You may download a few objects you already had. In return the server barely works. Small packs are merged in the background into bigger ones, like a log-structured merge-tree, which also lets Pando plan a fetch in logarithmic time.
There is a nice trick in the middle. When you push a feature branch, Pando only tells your client about trunk. On a repository with millions of branches, the full list can exceed 100 MiB. Your push ends up a little bigger (the median was still under 20 KiB), but anyone who already has trunk can fetch your branch with that one pack.
The numbers
- Median push latency down by nearly 5x, which is close to 80%.
- Close to a petabyte of Git data served a day, from a handful of CPU cores, and more than 57 TB in a single peak hour with over 99% of the bytes coming from cache.
- Clones and fetches that saturate 10 Gbps links on ordinary cloud VMs.
- Post-merge reliability at 99.99% after the cutover.
- In their simulation of 1,000 writers each pushing to their own branch, every writer finished in about 7.7 seconds on Pando, against roughly 57 seconds for three-phase commit and 96 seconds for the write-ahead log. OpenAI labels that simulation a teaching model, not a production benchmark, so treat it as an illustration of the shape, not a measurement.
And the detail I keep coming back to: Pando was built with Codex, from kickoff to production in ten weeks. One engineer designed the core, teams of agents implemented it, and agents wrote Lean and TLA+ specifications to find bugs. The agents built the system that made room for more agents.
The question Pando leaves open
Look again at bet one. Pando decides two writes are unrelated by branch name. That is the right call for a storage system. But it is not the question that hurts teams running a lot of agents.
Two agents on two branches can both rewrite checkQuota(). To Pando those pushes are independent, and it accepts both, fast, in parallel, without a lock. That is exactly what it was designed to do. Then CI fetches both, also fast, and the clash turns up at merge time, or worse, merges cleanly and is wrong.
Pando made that path much faster. It did not shorten it. The collision still happens. You just find out sooner.
Nool asks a different question: should these two agents be touching the same code right now? It answers before anyone types:
nool announce intent --agent-id quota-agent --intent "Tighten quota checks" --target-nodes src/api/limits.ts
nool discover conflicts --as-agent quota-agent src/api/limits.ts
nool propose --as-agent quota-agent --path src/api/limits.ts --intent "Tighten quota checks" --solidifyThe first agent takes a lease on the code it plans to change. The second agent's announce hits that lease and is told immediately, not an hour later in CI. The fleet planner goes a step further and sorts a whole task list into waves that cannot collide, and the semantic blast radius catches the overlaps that a text diff cannot see. Proposals then land through a gate: affected tests, policy and a signed record of who changed what, and why.
We measured what this buys. In a pre-registered benchmark with 35 agents working 60 tickets, a fleet on plain git had 33 to 62% of its tickets accepted. With Nool coordinating the same work, 98 to 100% were accepted, with zero merge conflicts.
Where each one works
| | Pando (OpenAI) | Nool | |---|---|---| | Problem it solves | Too many writers and readers for one git server | Too many agents for one shared understanding of the code | | Unit of "unrelated" | A branch | A file or symbol that has been leased | | When an overlap is found | At merge or in CI | At announce time, before the edit | | Interface | Unchanged git client | nool commands, the MCP server, or nool code | | Record of why a change exists | Commit messages | Intent, evidence and approvals on every change | | Scale it is proven at | A petabyte a day, thousands of concurrent pushers | Tens of agents per repository, many repositories per workspace | | Can you use it | Internal to OpenAI, though their git fork is public | Today, on the repositories you already have: set it up |
Where Pando is far ahead
I want to be clear about this part, because comparison posts usually are not.
Nool is not a git server and does not try to be one. If your problem is that a few thousand clients are hammering one monorepo, Nool will not make your fetches faster, and Pando will. Nothing we have built serves a petabyte a day, and we have never had to. Our own ledger has had storage growing pains on a much smaller scale.
Landing through Nool's gate also takes a few hundred milliseconds of checks. At our scale that disappears inside the model call before it. At OpenAI's push volume, that is the kind of overhead you would have to design around, and they are right to be obsessed with push latency.
And OpenAI is upstreaming its client fixes, including faster parallel pack downloads and a way to push a branch against trunk alone. Those will make git better for everyone, us included.
They stack
These are not rival products. They are layers.
Pando is a very good answer to "how fast can bytes move". Nool answers "who should be writing which bytes, and can we prove what landed". Nool mirrors every landed change to an ordinary git remote, so it will sit on top of GitHub, GitLab, or a Pando-style store when one exists outside OpenAI. That is the same conclusion I reached about Anthropic's Scion: a faster store still needs a coordination layer on top.
What is new is the trend. Within a month, two of the biggest AI labs have published how their agents broke source control. Both fixed throughput first. Both are honest that coordination is the next problem. Most teams will hit the coordination problem long before they hit a petabyte a day.
If you are running agents today
Ask yourself one question: when two of your agents edit the same function on different branches, when do you find out?
If the answer is "in CI" or "when a human reviews the merge", start with five Claude Code agents on one repo, or put Nool on your own repository in a few minutes. AI code governance covers the audit side, and teams can compare plans and pricing.
Further reading
What is agentic version control? compares Pando with Scion, Origin, jj and Nool in one table.