What Pando does
Pando is the Git backend OpenAI built after commits landed on its monorepo grew more than fourteenfold in under three years, driven by Codex. Each push is stored as an immutable packfile and recorded as a new version of its branch, so pushes to different branches proceed independently. Reads reuse packs from regional caches instead of building one per client. OpenAI reports median push latency down nearly 5x and close to a petabyte of Git data served a day.
What Nool does
Nool sits above the store. Before an agent edits shared code it announces intent and takes a lease on the files or symbols it will touch. A second agent that wants the same code learns about it at announce time, and the fleet planner puts overlapping tasks in separate waves. Changes land through a gate of affected tests and policy, and each one carries its intent and evidence.
Where Pando is ahead
Raw throughput and read scale. Nool is not a git server and will not make fetches faster. Pando serves tens of terabytes an hour from a handful of cores and lets thousands of clients push at once. If your bottleneck is the server under your monorepo, Pando's design is the one to study.
Where Nool is ahead
Coordination and availability. Pando decides that two writes are unrelated by branch name, so two agents rewriting the same function on different branches still collide at merge. Nool finds that overlap before the edit. And Nool installs today on the repositories you already have, while Pando is internal to OpenAI.
The same scenario in both
Two agents start on separate branches, and both decide to rewrite checkQuota(). On Pando both pushes are accepted in parallel, CI fetches both from cache at line rate, and the clash shows up when the second branch merges, or it merges cleanly and is wrong. With Nool the first agent's announce takes a lease on checkQuota(). The second agent's announce hits that lease straight away, so it waits, picks other work, or the fleet planner moves it to a later wave. Both changes still land, one after the other, each through the gate.
Using both ideas together
They compose. A Pando-style store moves bytes fast and keeps pushes from queueing. A coordination layer decides who should be writing which bytes, why a change was allowed, and what the next agent should know. Nool mirrors every landed change to an ordinary git remote, so it can run on GitHub or GitLab today and on a faster store later. If your agents already overlap in CI, coordination is the part you can adopt this week.
Pando vs Nool, side by side
| Criterion | Pando | Nool |
|---|---|---|
| Primary problem | Too many writers and readers for one git server | Too many agents editing the same code |
| Unit of "unrelated" | A branch | A leased file or symbol |
| When overlap is found | At merge or in CI | At announce time, before the edit |
| Interface | Unchanged git client and protocol | nool commands, the MCP server or nool code; mirrors to git |
| Availability | Internal to OpenAI; its git client fork is public | Installable CLI with a free Community tier |
| Evidence | OpenAI's reported push latency, throughput and cache hit rate | Pre-registered 35-agent benchmark: 98 to 100 percent of tickets accepted vs 33 to 62 percent for a plain git fleet |
Frequently asked questions
- Is Nool a replacement for Pando?
- No. Pando is a Git server backend. Nool is a coordination and governance layer that works on top of git. They could be used together.
- Can I use Pando?
- Not today. OpenAI describes Pando as internal and says it is exploring ways to share the underlying technology. Its git client fork is public, and some fixes are already upstream.
- Does Nool slow pushes down?
- Landing through Nool's gate adds a few hundred milliseconds of checks, which disappears inside the model call before it for most teams. At OpenAI's push volume that would matter, which is one reason a fast store and a coordination layer are separate jobs.
- Do I need a monorepo to benefit from Nool?
- No. Nool works per repository and nests repositories into a workspace. The coordination problem appears as soon as two agents can touch the same code, long before a repository reaches Pando's scale.