Within just three weeks, two top AI labs delivered completely opposite diagnoses for the exact same engineering problem. In mid-October this year, Anthropic announced that its single monorepo could no longer keep up with the high-frequency reads and writes of coding agents. So they brought together 7 engineers and spent 5 months building a brand-new version control system called Scion, replacing the client CLI, underlying storage, and surrounding tools like code review from top to bottom. For the specific trade-offs, see our previous article on how Anthropic rebuilt its code infrastructure.
Just three weeks later, OpenAI introduced its own solution, Pando, in its November 2 engineering blog post. They faced a similar crunch: once Codex agents became widespread, a single engineer often had multiple changes waiting on continuous integration at the same time. Compared with the first quarter two years ago, code commits in the third quarter of this year grew nearly fourteenfold, and the fourth quarter is projected to reach roughly twenty-five times that baseline.
Under that concurrency wave, OpenAI’s legacy Git backend began stalling frequently late last year, and the reliability of routine branch merges briefly dropped below 90%. Yet OpenAI did not abandon Git. Instead, 1 engineer designed the core architecture and led multiple teams of Codex agents to rewrite the server side in 10 weeks. After the overhaul, the everyday Git commands typed by engineers and agents stayed the same and the backend remained compatible with the standard Git protocol, while median push latency dropped by nearly 80% and the system steadily distributed nearly 1 PB of code data per day.
Faced with the same surge of agent reads and writes, why did one lab throw out Git entirely while the other rebuilt only the backend and kept the client intact? In their blog post, the three OpenAI authors—Aaron Friel, Taylor Blau, and Ted Nyman—posed a pivotal question: is the problem Git itself, or the traditional way servers host a single monorepo?
Anthropic concluded it was the former: designed for offline humans, Git’s architecture no longer fits the agent era. OpenAI concluded it was the latter: Git’s wire protocol and data format are fine, and the real bottleneck came from two extra constraints that traditional servers imposed on themselves. To understand why, we first need to look at how OpenAI relaxed those server-side read and write constraints, and then look at the people behind each team.
Let’s start with the traffic jam when pushing code. Once Codex agents took off, a single large repository at OpenAI could easily hold millions of branches at once. Intuitively, if Agent A is updating its own feature branch and Agent B is updating a completely unrelated branch, they are working on separate tasks—why would their pushes block each other or even time out?
The answer goes back to how Git records a branch. Every branch name in a Git repository is essentially a lightweight text file pointing to the hash of its latest commit, which we will call a branch pointer. Each time a client pushes code, it compresses the new commits, directories, and files into a binary data bundle called a packfile and uploads it to the server. Only after the server receives the packfile and moves the corresponding branch pointer to the new hash is the push complete.
To guarantee data safety, traditional Git servers have long held to a conservative rule: whenever anyone reads the repository, all several million branch pointers must form a single snapshot aligned at the exact same instant in time. Historically, systems used one of two approaches to enforce that repo-wide snapshot.
The first approach has multiple servers—each holding a full copy of the repository—communicate and vote on how to update branch pointers, known in distributed systems as three-phase commit. GitHub’s long-serving Spokes storage engine took this path. The second approach has write nodes upload packfiles in parallel to cloud object storage and then compete to atomically update a single global log manifest, using a write-ahead log and compare-and-swap. A concrete example can be seen in the cloud log design Cursor recently shared.
Although the two approaches differ in implementation, both hit the same wall. Because the server insists that every branch stay aligned at the exact same moment, even updates to millions of unrelated branches have to be serialized. Ultimately, the write throughput of the entire repository is capped by its slowest replica—or by the lock on that single global log manifest.
When the OpenAI team stepped back and looked at real-world coding and testing workflows, they realized that keeping millions of branches synchronized to the same millisecond was an unnecessary constraint. Whether it is a test runner or an agent, each job only pulls the specific feature branch it is working on, plus the main branch. In practice, no task ever needs to inspect two unrelated edge branches at the exact same instant.
Once that clicked, Pando simply removed the single giant lock over the whole repository and let each branch keep its own ledger. Previously, millions of branches were squeezed into one global manifest where every update had to fight for the same lock. Now, each branch pointer is an independent row in a database: after the code packfile is written to cloud object storage, Agent A pushing branch A only updates row A, and Agent B pushing branch B in the same millisecond only updates row B. Millions of branches went from queuing on a single-plank bridge to driving in their own lanes, and unrelated pushes no longer wait on a global lock.
The only special case to handle is when branch B has just been cut from branch A. If the two are updated independently, what happens if someone pulls branch B and cannot find the underlying code from branch A? Pando’s solution is straightforward: when updating branch B, it records which commit on branch A it branched from, so anyone pulling branch B can follow that pointer and retrieve the full upstream history. That way, branches with an upstream-downstream relationship never lose history, while unrelated branches stay completely independent. The only trade-off is that if someone reads two completely unrelated branches at the exact same moment, they might see states a few milliseconds apart—which does not matter at all in day-to-day development. Interestingly, in late October, GitHub’s next-generation architecture overhaul made a similar trade-off, breaking up its thirteen-year-old repo-wide lock into per-branch locks.
With the write lock out of the way, the read storm is an even bigger test for the server. Every code push inside OpenAI triggers waves of test runners, research jobs, and other agents pulling the latest commits simultaneously, reaching a peak traffic of 57 TB in a single hour. Since hundreds or thousands of machines are pulling the exact same code, why can’t a traditional Git server hand out static cached files like a regular CDN, instead of burning massive CPU power repacking data on the fly for every request?
Normally, if you cut a new branch from the main branch, edit some code, and pack all your changes relative to main into a single bundle for the server, then when hundreds of test machines that already have the main branch come to pull your new branch, the server should be able to hand them the exact bundle you just uploaded. Traditional Git doesn’t do this, because of a clever-by-half handshake right before the push. Before every push, a traditional Git server lists the latest positions of all several million branches in the repository and sends that giant manifest to the client—at OpenAI, transmitting that list alone took over 100 MiB of traffic.
After receiving the list, the client runs a penny-pinching exclusion step to save a few kilobytes of upload bandwidth: if it notices that a few files you edited happen to look a lot like code sitting on some obscure branch from another team, it only packs and uploads the diff against that obscure branch. Saving that tiny bit of upload bandwidth wrecks the pull phase that follows. The packfile you uploaded is now half a sentence that can only be reconstructed together with your colleague’s obscure branch. A second later, when hundreds of test machines come to pull your branch, they only have the main branch locally—not that obscure branch—so they cannot unpack the bundle you just uploaded. Left with no choice, the server has to diff commit histories in the background every single time, burning massive processor resources to custom-build a fresh packfile for each test machine.
Once you see this knot, Pando’s fix is remarkably simple: before a push, the server hides those millions of feature branches from the client by default and only advertises the position of the main branch. Thinking the server only has the main branch, the client dutifully packs all changes made on the current branch since it diverged from main into a single self-contained bundle. Pushing repeatedly to the same branch does re-upload the changes since diverging from main, but feature branches are short-lived and consist of highly compressible plain-text code. In practice, the median feature-branch packfile is under 20 KiB, and 99% of them are smaller than 3 MiB.
Paying a few kilobytes of extra upload cost eliminates on-the-fly computation during pulls altogether. Because the packfile uploaded by the client depends only on the main branch, hundreds of test machines and agents that already have the main branch can unpack it directly when pulling the feature branch. The server simply hands out the exact packfile it just saved to object storage, without spending a single second of CPU time repacking.
Since every code bundle is now a directly reusable static file, Pando
even relieves the Git server of forwarding the file bytes itself. It
enables an existing mechanism in Git protocol v2 called
packfile-uri: when a client pulls code, the Pando server
simply checks its metadata directory and returns a list of static
download URLs. The client takes those links and downloads the static
packfiles in parallel from the nearest node of Express, OpenAI’s
in-house regional caching service, just like streaming a video from a
CDN. In production, over 99% of data bytes hit the local disk of the
cache nodes directly, saturating a 10 Gbps network link even on ordinary
cloud virtual machines.
The only remaining wrinkle is that the main branch receives tens of thousands of merges every day. If cloud storage only ever kept the tiny packfiles left behind by each individual push, a machine that had not updated in a few months would have to download tens of thousands of tiny fragment files at once. To solve this fragmentation problem, Pando runs an automatic background compaction process—much like a bank bundling loose coins into rolls—that periodically merges and compresses consecutive small packfiles into larger rollup bundles spanning multiple commits, organized from small to large across five tiers from level zero to level four.
Whereas traditional Git deletes the old small packfiles after housekeeping, Pando keeps every tier—from level-zero tiny packfiles up to level-four large rollup bundles—in inexpensive object storage. That way, no matter how many steps behind a client is when it pulls code, the server can assemble the missing history using the fewest possible files, just like making change with the right bills and coins: an agent that is only two commits behind grabs two level-zero packfiles of a few kilobytes each, while a new machine that is months behind grabs a few top-tier rollup bundles, and neither has to wait for the server to pack anything on the fly.
At this point, a natural question arises: if keeping everyday Git commands and protocol compatibility could solve the read and write bottlenecks so cleanly in 10 weeks, why did Anthropic go to the trouble of throwing out Git? Did the two labs take opposite paths because their objective workloads differed, or because the engineers at the helm looked at the problem through different lenses? Tracing the backgrounds of the authors behind the two technical blog posts reveals that the core answer lies in their engineering DNA: the tools you know best shape the root cause you see.
Look first at Anthropic’s Scion team. As the open-source community debated why Scion looked so much like Meta’s internal systems, Scion’s core author candidly shared their background in a community thread. Anthropic has many former Meta engineers who had a great experience using Meta’s in-house Sapling client and Mononoke server, so from day one, Mononoke served as the team’s North Star. When these engineers—steeped in Meta’s developer infrastructure—saw Git’s high-concurrency alarms go off, they naturally reached for the playbook Meta used to replace its legacy tools: stop recording the entire directory tree on every commit like Git does, record only which files changed in each commit, store loose file blobs in cloud object storage, and use AI-accelerated coding to rewrite the client CLI and six surrounding developer tools in 5 months.
The three authors of OpenAI’s Pando come from a very different camp. Second author Taylor Blau is a core maintainer of the Git project and a member of the Git Leadership Committee; before joining OpenAI, he served as Staff Engineer for Git Infrastructure at GitHub. Many of the core storage features that accelerate large repositories in modern Git—including geometric repacking, multi-pack indexes, and reachability bitmaps—were his work in the first place. Third author Ted Nyman was formerly Director of Infrastructure Engineering at GitHub.
When you ask a core Git storage maintainer to diagnose why a monorepo
is slowing down, he is naturally not going to conclude that the Git
protocol belongs in the trash. He could see right away that Google
engineers had already introduced packfile-uri into the Git
protocol back in 2020 specifically to offload packfiles to CDNs—it was
just that over the past six years, very few Git servers had ever put the
feature into practice.
If Google put packfile-uri into Git six years ago, why
did almost no major company actually use it all these years? A look at
OpenAI’s public patch
tracker tells the story: what landed in the official Git tree years
ago was really an experimental half-finished feature that had never been
battle-tested under nearly 1 PB of daily production traffic. Once you
actually split code into pre-built static packfiles and hand them
directly to clients—or hide other branches during a push like Pando
does—the aging C code deep inside the stock Git client starts tripping
over itself: for instance, throwing false-alarm errors when it sees
duplicate files across two static packfiles, or refusing to run safe
force-push checks because the other branches were hidden.
This is the exact moment where team DNA separated the two paths. When an ordinary engineering team runs into dozens of decades-old quirks in Git’s low-level C codebase, they will likely conclude the antique is impossible to fix and write a new client from scratch. For Taylor Blau and Aaron Friel, who live and breathe Git source code every day, what looks like an impenetrable black box to others feels like their own living room. They went straight in and made 50 surgical fixes to Git’s C source code, packaged an internal build for employee machines and containers, and steadily contributed the patches back to the upstream open-source community. The Git protocol was not born perfect, but people who know the anatomy of its heart know how to perform micro-surgical bypasses on it.
Beyond team DNA, two objective differences in their operating environments also pushed the labs in different directions. First, their write traffic concentrates in different places: Anthropic merges over 30,000 commits a day directly into the same main branch, whereas OpenAI’s concurrency pressure is spread across millions of independent feature branches. Second, their client environments and firefighting timelines differed: Anthropic’s agents mostly run inside controlled online containers in data centers, giving the engineering team nearly half a year to replace the full toolchain; OpenAI’s Codex not only runs in the cloud, but is also embedded directly inside the cross-platform ChatGPT desktop app on users’ computers. With branch merge reliability already dipping below 90% late last year, OpenAI’s team had to stop the bleeding within a little over two months—and under those constraints, asking every desktop app and surrounding tool to give up standard Git commands was simply off the table.
The way Pando itself was built is a microcosm of how engineering is evolving in the agent era. The entire backend went from kickoff to production in just over two months, with a single engineer designing the core architecture and multiple teams of Codex agents writing the implementation from scratch in Rust. To make sure high-concurrency reads and writes never drop code, alongside standard conformance tests and deterministic simulation, OpenAI also ran the GPT-6 Astra model continuously for hundreds of hours. The model wrote mathematical formal specifications in Lean and TLA+ to exhaustively hunt down edge-case bugs in concurrent branch negotiation and pack compaction. Compared with the single-threaded machine-code verification covered in our earlier article on AI-assisted formal verification, large models are now helping engineers tackle complex distributed concurrency state machines.
Putting Anthropic’s Scion and OpenAI’s Pando side by side offers a clear decision framework for every engineering team. Over the past month alone, four companies—GitHub, Cursor, Anthropic, and OpenAI—almost simultaneously rebuilt their version control infrastructure for coding agents. AI coding tools have sped up writing code by orders of magnitude, making it cheaper and cheaper to spin up a squad of agents and rewrite tens of thousands of lines of low-level systems and surrounding tooling in a few months.
As rewriting code gets cheaper, a common trap is to tear everything down and start over the moment a system hits a performance wall. The story of OpenAI’s Pando points to an opposite—and increasingly scarce—skill: when facing an aging system that looks tapped out, knowing how to tell which parts are load-bearing external contracts that everything depends on, and which parts are just outdated internal assumptions tying your hands. Keeping the external CLI and ecosystem contract intact, loosening the internal assumptions of repo-wide synchronization and on-the-fly packing, and clearing the roadblocks with surgical low-level patches—that engineering judgment to separate contract from implementation has become far more valuable in the agent era than writing code itself.