Commits to the main branch of OpenAI's monorepo grew 1,378% between Q1 2024 and Q3 2026, mostly because of Codex. Under that load, the previous Git backend's reliability sometimes dropped below 90%. OpenAI's answer, published on November 2, 2026, is Pando: a Git-compatible backend that cuts median push latency by nearly 80% without asking anyone to switch clients.
The contrast is what makes it interesting. In October 2026, Anthropic explained how it had solved the same problem by dropping Git from its monorepo altogether. Two labs, the same root cause (agents write far more code than people do) and two opposite answers.
The problem: Git wasn't built for thousands of agents pushing at once
A classic Git server treats the repository as one unit with a global order: every ref update is serialized against every other. With human teams you barely notice. With agents branching, pushing and merging around the clock, that serialization becomes the queue everyone waits in. The other half of the problem is reads: every clone or fetch makes the server compute a custom packfile, and CI and agents clone constantly.
OpenAI doesn't publish pushes per second or the number of concurrent writers. It does share the growth curve, and its estimate for Q4 2026 climbs to 2,442%.
The fix: causal consistency and reusable packfiles
Pando replaces the server side and leaves the protocol and clients untouched. The two key decisions:
- Causal consistency instead of repository-wide consistency. Pushes to different refs go ahead in parallel; only pushes to the same ref are ordered against each other. The trade-off is stated plainly: a client reading several branches can't assume they all reflect the same point in time.
- Reads served from cache. Instead of building a packfile per client, Pando reuses packfiles it has already computed, so it can hand the same bytes to many clients with very little compute.
It's written in Rust and went from kickoff to production in about 10 weeks, taking real traffic since April 2026. One engineer designed the core, teams of Codex agents implemented it, and a handful of engineers rolled it out.
The results OpenAI reports:
| Metric | Pando |
|---|---|
| Median push latency | nearly 80% lower than the previous backend |
| Git data served | close to 1 PB per day |
| Peak | more than 57 TB of packs in one hour |
| Served from local disk | over 99% of that peak |
Pando vs. Scion: compatibility or a rewrite
Anthropic sized its problem differently: from 2,500 merges a day in May to more than 30,000 in September, a main-branch history of almost 100 GB, and roughly 25 million CI checkouts a day. Its answer, Scion, is a brand-new version control system that moves the work to the server: commits happen there, and a checkout only pulls the directories it asks for, fetching files as they're read. Adopting it means replacing code review, code search and CI along with it.
| Pando (OpenAI) | Scion (Anthropic) | |
|---|---|---|
| Relationship with Git | Keeps clients and protocol | New system; also replaces review, search and CI |
| Writes | Causal consistency: parallel pushes per ref | Commits are made on the server |
| Reads | Cached packfiles, over 99% from local disk | Partial checkouts; files fetched as they're read |
| Team and timeline | 1 engineer on design, agents, a few to deploy; 10 weeks | A small team plus a lot of Claude; about 5 months |
| Headline result | Median push nearly 80% faster | 200x less CPU and memory than the Git mirror fleet |
| Source code released | No | No |
These are two different bets. OpenAI takes on the cost of preserving Git semantics on the server so that no tool, IDE or pipeline has to change. Anthropic takes on a migration of the whole development lifecycle so that no client ever has to clone the full repository. Both agree on the essentials: at this scale, the expensive part is moving the same bytes over and over, and the winner is whoever stops computing or sending them per client.
What's worth taking away
The lesson I find most useful is about consistency. Almost nobody needs every branch in a repository to advance in a single global order; what you need is an order within each branch. Relaxing that guarantee is what turns a bottleneck into a system that scales by adding machines, and the same idea applies to a queue, a config store or an artifact registry.
The second is to measure before it hurts. Once your team starts handing work to agents, pushes, fetches and CI runs stop growing with headcount and start growing with open agent sessions. Watching push latency and the CI queue as closely as you'd watch a production service is what gives you warning in time.
The third: compatibility is worth a lot. Pando reached production in 10 weeks partly because it didn't have to convince anyone to change tools.
What doesn't transfer
Neither system is open source, and neither company has published a deployment guide. The numbers are each lab's own, with no independent benchmark. For a monorepo of a few gigabytes and a few dozen engineers, hosted Git with partial clones and a CI that reuses caches is still plenty; this only starts to matter when agents multiply your writes tenfold.
Sources
- Scaling Git at OpenAI (OpenAI, November 2, 2026)
- OpenAI details Pando Git backend after Codex commit surge (AI Weekly, November 3, 2026)
- Scaling Git at OpenAI (daily.dev)
- Why Anthropic replaced Git, and whether you'll need to (Arize, October 2026)