When Codex Broke Git: OpenAI Built Pando, Anthropic Left Git Entirely
By Arash Latifi
Two engineering posts in one week: OpenAI rewrote its Git backend (Pando, ~5x lower median push latency, ~1 PB/day) while Anthropic migrated its monorepo to a custom VCS (Scion, 30,000 merges/day). What actually transfers to small teams.
TL;DR — OpenAI kept Git and rebuilt the backend (Pando: ~5x lower median push latency, nearly a petabyte of Git data per day); Anthropic ditched Git for Scion in five months (30,000+ merges/day, 200x smaller infra footprint). Both confirm the same thing: coding agents broke human-scale infrastructure, and neither solution is magic you can copy.
The actual problem
For two decades, Git scaled to anything humans threw at it. Now the two companies running the most coding agents on Earth both report it cracking:
- OpenAI: starting late last year, the systems serving their monorepo struggled — slow fetches and pushes, failed merges, reliability at times below 90%. Cause: Codex. One engineer now has several changes ready for CI at once, and each push wakes jobs that all fetch the same commit.
- Anthropic: ~2,500 code changes merged per day in May 2026; over 30,000 per day by September. Their main branch history alone is almost 100 GB, with ~25 million code checkouts per day for CI — naively fetched, over 600 PB of Git traffic per day.
The shared diagnosis: the bottleneck is no longer writing code; it's developer infrastructure built for human scale.
Two answers to one problem
| | OpenAI — Pando | Anthropic — Scion | | --- | --- | --- | | Approach | New backend, fully compatible with Git protocol and client | Brand-new VCS, full monorepo migration in 5 months | | Key tradeoff | Drops repo-wide point-in-time consistency (causal consistency) | Abandons Git's distributed model — everything server-side | | Headline result | Median push latency cut ~5x; ~1 PB of Git data delivered daily | 200x smaller infra footprint; checkouts 100x faster (seconds, not minutes) | | Team | Core designed by one engineer, implemented by agent teams — production in 10 weeks | Team of 7, plus code review (Antique), code search, and IAM |
What Pando does: instead of computing a bespoke packfile per client (expensive CPU/IO, nearly uncachable), it stores the packfiles pushed to it and serves the same bytes to every reader. For fetches it leans on an under-appreciated Git protocol feature, packfile-uri — the server sends an empty inline pack plus links to additional packs — and OpenAI contributed upstream improvements to it. The scaling tradeoff: a reader looking at several branches can't assume they're from one point in time; only per-ref ordering is guaranteed. Packs are compacted in the background into L0–L4 "covers" (like LSM-tree levels) so a lagging client doesn't download tens of thousands of tiny packs.
What Scion does: the inverse model. Clients compute almost nothing; commits, merges, and diffs happen server-side. The unit of work is a "changeset" storing only files changed relative to the first parent, with content-addressed pointers to compressed blobs. Since nothing immutable ever changes, any server caches anything without coordination — there are no packfiles to maintain at all. Fetch negotiation doesn't use haves/wants: the client recursively requests just the missing trees and blobs, each an immutable object any cache tier can serve (cache hit rates over 99% per tier).
What transfers to your small project
You won't run either system — Anthropic explicitly says Scion "is by no means a suitable replacement for git for general use." Three lessons still port:
packfile-urideserves a look. If you self-host Git, this standard protocol feature lets large packs be served from a CDN or object storage separately — the exact trick Pando uses exclusively.- Content-addressed caching is the cheapest scaling primitive. Immutable objects = caches everywhere with zero coordination. The same principle works in your CI (build caches keyed on input hashes).
- [ ] Confirm your CI build/repo caches are keyed on immutable input hashes, not timestamps
- [ ] Squash agent-generated fix-commit chains into meaningful PRs before merge
- [ ] Check whether your Git hosting supports
packfile-uri(or a CDN in front of large packs)
- Commit count is not a quality metric. The HN thread on OpenAI's post (245 points) kept circling one worry: agent-scale history is often "slop, slop to fix slop" — many tiny fix commits, a bloated base that costs more context for every future agent run. For small teams, squashing and meaningful PRs still matter, even with agents writing the code.
And a process lesson from Anthropic: their engineers say their main role during the migration was telling Claude "no" — blocking over-engineering and constraint violations. Humans still review every change, but they review the intent of a change, not every line.
Q: Are Pando and Scion available to the public?
Not yet. OpenAI says it's "exploring ways to share the technology that makes Pando possible" and keeps contributing to upstream Git (including the packfile-uri improvements). Anthropic states plainly it won't offer Scion publicly — it's too entangled with their bespoke review, search, and CI stack.
Q: Is Git dying?
No — quite the opposite. OpenAI deliberately kept the Git protocol and client; Anthropic argues Scion's ideas can land inside the Git ecosystem (server-side RPCs, better negotiation, composable sparse/shallow features). For any repo that isn't a 100 GB monorepo doing 30,000 merges a day, Git remains the right tool.
Q: When should a small team actually worry?
When you see OpenAI's symptoms for real: slow fetches/pushes, broken merges, CI queuing because dozens of jobs fetch the same commit. Until then, repo hygiene (small packs, squashing, lightweight mirrors) is enough. Anthropic's own caveat: these problems "really only make sense for truly enormous monorepos" — though they expect the class of problems to become common within 6–12 months.