OpenAI and Anthropic Both Outgrew Git. What Should Your Team Change?

On 2 November, OpenAI published a long engineering post about Pando, a new Git backend that now serves its entire monorepo. Three weeks earlier, Anthropic had described Scion, a source control system that replaced Git on its own monorepo. Both companies gave the same reason: coding agents were producing and fetching code faster than the old setup could handle. "Git is dead" headlines followed.

Git is fine for nearly everyone reading this. The two posts are still worth your time, because they name the exact places where agent traffic hurts, and several of those places show up in much smaller repositories. This article covers what each company built, where their designs disagree, and what a normal team can change this week with stock Git. The Git tests below were run on real repositories, with the results included so you can compare them with your own.

What OpenAI built

Pando is a server. Engineers and agents keep the Git protocol and the Git client, and only the backend changes. OpenAI says the system behind its monorepo started struggling around the end of last year, with slow fetches and pushes, and with merge reliability that sometimes fell below 90%.

The design gives up two things most Git servers treat as requirements.

The first is a consistent view of every ref at one moment. Pando coordinates each branch on its own, so pushes to unrelated branches never wait for each other. The cost is that a client looking at several branches can see them at different points in time. OpenAI's argument is that users and agents depend on the order of updates to one ref, and almost never on a global order.

The second is a custom packfile for each client. A normal server computes which objects a client is missing and compresses them on the spot, which is expensive and hard to cache. Pando keeps the packfile from each push in blob storage and reuses it for later fetches. A client may download a few objects it already has, and in exchange the server spends very little compute. OpenAI uses Git's packfile-uri feature to hand clients links to those files, and serves them from regional caches.

The reported results: median push latency down by nearly 80%, close to a petabyte of Git data served per day, and more than 57 TB of packs served in one hour with over 99% of the bytes coming from local disk cache. OpenAI also says it built Pando with Codex in 10 weeks, with one engineer designing the core and teams of agents implementing it, in Rust. It started taking production traffic in April. These are the company's own numbers, and nobody outside can check them.

What Anthropic built

Anthropic went further. Its post says merges to its monorepo went from about 2,500 a day in May to over 30,000 a day in September. Main branch history is almost 100 GB, a compressed working copy is over 25 GB, and CI alone runs about 25 million checkouts a day. It had already tried shallow clones, sparse checkouts, promisor remotes and several hundred internal Git mirrors.

Its diagnosis was that almost every client was an always-online job or agent, so Git's offline-first model was working against it. Scion moves the work to the server. Commits, rebases and merges happen there. Blame, history and diff are API calls, so many jobs need no local repository at all. Working copies are optional and virtual, and files appear when something reads them.

A seven-person team did this in five months. Anthropic reports a footprint about 200 times smaller than the mirror fleet it replaced, and CI checkouts dropping from minutes to seconds. It also gives up something most teams rely on: a merge queue with a global lock. It tests after merge and before deploy, and has Claude fix the conflicts that come up.

Scion will not come to your laptop. The post says it is "by no means a suitable replacement for git for general use", and adopting something like it would mean moving review, search and CI as well.

Where the two designs disagree

Question	Pando (OpenAI)	Scion (Anthropic)
Git client and protocol	Kept	Diverges from Git
Where commits are created	On the client, then pushed	On the server
Local clone	Yes, and fetches run as fast as the network allows	Often none, with on-demand files
Branches	Many, each coordinated separately	Discouraged beyond main and release branches
Availability outside the company	OpenAI says it is exploring ways to share the underlying technology, and it sends client fixes upstream	Not offered, design ideas shared instead

Both agree on the part that matters for you. The expensive shared resource is coordination between writers, plus the compute needed to prepare data for readers. Each design removes those costs by dropping a guarantee that agents turned out not to need. You can apply the same reasoning to your own repository without touching a server.

Read the 2,442% figure carefully

Many reports repeat that commits to OpenAI's monorepo grew 2,442%. In OpenAI's chart, that value is the estimate for Q4 2026, measured against Q1 2024, and the quarter isn't finished yet. The last measured quarter, Q3 2026, shows +1,378%. That is still a huge jump, and the index for Q3 was nearly double Q2's. If you quote this number, say it is an estimate.

Is this coming for your repo?

Some of it already has. GitHub's October infrastructure post says monthly pushes grew 4.9 times in a year, from 0.69 billion to 3.35 billion. Octoverse reports that more than 40% of pull requests were started by an agent as of September 2026, up from 17% in March. GitHub is moving repository data to Azure Blob Storage and shrinking the part of a push that needs agreement between replicas, and it says this needs no workflow changes from users.

So the hosting side is being rebuilt for you. What's left is your own side: how agents clone, how they push, and what your CI fetches. Measure those before changing anything:

# Commits on the default branch in the last 30 days, by week
git log --since="30 days ago" --format=%ad --date=format:%Y-W%V | sort | uniq -c

# How many refs and how much packed data you carry
git for-each-ref | wc -l
git count-objects -vH

# How long a fresh agent checkout really takes
time git clone --filter=blob:none --sparse <your-repo-url> /tmp/clone-test

If the weekly counts have jumped and agent sandboxes spend real time cloning, the next two sections apply. If a fresh clone takes a few seconds and nobody is fighting over main, leave your setup alone.

A clone test on a real Swift repository

The numbers below come from one run on 5 November 2026, using Git 2.43.0 on a Linux cloud machine, against the public swiftlang/swift-package-manager repository. At the time it had 9,275 commits on the default branch and 2,683 tracked files. It is a mid-sized repo, so treat the ratios as the useful part. Network speed will change the seconds.

Strategy	Time	.git size	Total on disk
Full clone	7.6 s	48 MB	79 MB
Blobless (--filter=blob:none)	3.9 s	18 MB	50 MB
Treeless (--filter=tree:0)	3.5 s	11 MB	43 MB
Shallow (--depth=1)	1.7 s	4 MB	36 MB
Blobless + --sparse, then two folders	2.7 s	15 MB	17 MB

The last row is the one to copy for agents that work in one area. It needed 158 of the 2,683 files, about a fifth of the full disk use, and it kept the commit history:

git clone --filter=blob:none --sparse https://github.com/swiftlang/swift-package-manager.git
cd swift-package-manager
git sparse-checkout set Sources/Basics Tests/BasicsTests

The trap: partial clones are slow at history

Shallow looks like the winner in that table until an agent needs context. The shallow clone had exactly one commit in git log, so git blame and any question about why a line changed have nothing to work with. That matters more than people expect, because agents read history to understand old code.

Blobless keeps the commits, and has a different problem. Running git blame Package.swift took 0.19 seconds in the full clone and 128 seconds in the blobless clone, a difference of nearly 700 times, while .git grew by only about 1 MB. Git had to fetch old versions of the file on demand, and its partial clone documentation lists per-object fetching as a known limitation. This is the same pain Anthropic described: diff and blame on partial clones got harder as the merge rate rose.

Three ways to live with it:

• Run git backfill after cloning. It downloads missing blobs in batches, and it respects your sparse checkout. It arrived in Git 2.49 and is marked experimental. The test machine ran 2.43, so it wasn't part of this run.
• Answer history questions through your host's API or web view when an agent only needs one fact.
• Keep one full clone on each developer machine and give agents worktrees from it, which the next section covers.

A push test: one shared branch against one branch per agent

Pando's central idea is that writers on different refs shouldn't wait for each other. Stock Git already behaves this way at small scale, as long as agents don't all push to the same branch. This script starts eight parallel agents against a local bare repository. Each one makes five commits and pushes after every commit.

#!/usr/bin/env bash
# usage: ./push-test.sh shared|own [agents]
mode=$1; agents=${2:-8}
rm -rf origin.git seed agent-* rejected.*
git init -q --bare -b main origin.git
git clone -q origin.git seed 2>/dev/null
( cd seed
  git config user.email test@example.com; git config user.name seed
  git checkout -q -b main 2>/dev/null
  echo hello > README; git add .; git commit -qm init; git push -q origin main )

run_agent() {
  id=$1; rejected=0
  git clone -q origin.git agent-$id; cd agent-$id
  git config user.email test@example.com; git config user.name agent-$id
  [ "$mode" = own ] && git checkout -q -b agent/$id
  for n in 1 2 3 4 5; do
    echo "$id-$n" > file-$id.txt; git add .; git commit -qm "agent $id change $n"
    if [ "$mode" = own ]; then
      git push -q origin HEAD:agent/$id 2>/dev/null || rejected=$((rejected+1))
    else
      until git push -q origin main 2>/dev/null; do
        rejected=$((rejected+1))
        git pull -q --rebase origin main 2>/dev/null
      done
    fi
  done
  echo $rejected > ../rejected.$id
}

start=$(date +%s.%N)
for id in $(seq 1 $agents); do run_agent $id & done
wait
end=$(date +%s.%N)
echo "$mode: rejected=$(cat rejected.* | paste -sd+ | bc) seconds=$(echo "$end-$start" | bc)"

Three runs of each mode gave these results:

Mode	Rejected pushes	Total time
All agents on main	127, 132, 145	6.2 to 6.5 s
One branch per agent	0, 0, 0	about 1.2 s

Forty pushes took between 167 and 185 attempts on the shared branch, and that was on a local disk with no network in between. Against a hosted remote, every retry adds a round trip, a rebase and possibly a CI trigger. A single run with 16 agents gave 559 rejected pushes in 22.5 seconds on the shared branch, against 0 rejections in 2.6 seconds with separate branches. The cost grows faster than the agent count, because each successful push invalidates every other agent's next attempt.

Separate branches move the conflict to merge time, and they don't remove it. They do let you decide when it gets handled, and it stops wasting agent time on retry loops. GitHub's merge queue is built for that second step on busy branches. Anthropic dropped its merge queue at 30,000 merges a day, and that decision says very little about a repository with about 50 commits a month, which is what the Swift repo above had over the last 30 days.

A setup for parallel agents with stock Git

Give each agent its own worktree and branch, and let them share one object store:

git fetch origin
git worktree add -b agent/payment-fix ../wt-payment-fix origin/main
git worktree add -b agent/ui-tests ../wt-ui-tests origin/main

# After the branch is merged
git worktree remove ../wt-payment-fix
git branch -d agent/payment-fix

Per the worktree docs, each worktree has its own HEAD and index, while branches and tags are shared. Git refuses to check out one branch in two worktrees, which is a useful guard here because two agents can't silently share a branch. In the test above, a worktree created inside a sparse clone kept the same sparse folders, so the two techniques combine with no extra step.

For CI, check what each job actually fetches. actions/checkout already defaults to one commit. Jobs that need history usually get fetch-depth: 0 and a full download, and a filter cuts most of that:

- uses: actions/checkout@v7
  with:
    fetch-depth: 0
    filter: blob:none
    sparse-checkout: |
      Sources/Basics
      Tests/BasicsTests

For a developer machine that holds a large repository, scalar clone ships with Git and turns on the same blobless, sparse setup plus background maintenance. On an existing clone, git maintenance start schedules hourly commit-graph updates and prefetching, so later fetches transfer less.

Notes for iOS repositories

Worktrees work well for Swift projects, with two costs to plan for. Xcode keys DerivedData by project path, so each worktree builds from scratch into its own folder. Pass a path you can delete when the worktree goes away:

xcodebuild test \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 17' \
  -derivedDataPath ./.build/derived

Add that folder to .gitignore. Then keep agents off the same simulator, because parallel test runs on one device interfere with each other. xcrun simctl clone gives each agent its own copy to target. Project files need attention too: two agents editing project.pbxproj on separate branches will conflict at merge, and Xcode's folder-based groups cut down how often that file changes.

Match the symptom to the fix

Symptom	Try first	Leave for later
Agent sandboxes spend minutes cloning	Blobless plus sparse clone, or a cached base checkout	A custom backend
Agents loop on rejected pushes	One branch per agent	Faster hardware
Agents give shallow answers about old code	Keep history, use blobless, run git backfill	--depth=1 everywhere
CI waits on checkout	Filters and sparse paths in the checkout step	Mirrors
Main breaks often after merges	A merge queue with required checks	Removing human review
Review can't keep up with agent output	Smaller changes and agent review before people look	Any change to source control

The last row is the one many teams will land on. Faster pushes won't help when people are the bottleneck, and Anthropic's engineers still review each change request, with attention on intent. OpenAI, for its part, built conformance tests and a deterministic simulation harness so agents could check their work against Git's standard behavior. Both companies treated checks on agent work as part of the system, and both still have people in the loop.

What to watch next

The useful part for most of us will arrive as Git releases and hosting upgrades. OpenAI says some of its client fixes are already upstream and tracks the rest in a public patch tracker, and it mentions parallel pack downloads in its own Git build. Anthropic hopes forges will adopt server-side queries for blame and diff, which would ease the partial clone problem shown above. GitHub's storage move should reach every repository with no action from you.

If your agents push to shared repositories, safety rules around them matter as much as speed. Ship It Solo: The Claude Code Agent Team Kit ($26) is a kit from this blog's store: a four-agent pipeline of spec-writer, implementer, reviewer and qa, with five slash commands and guard hooks, including one that blocks force-pushes to main. It covers the review and safety side of this article, and its product page lists nothing on clones or worktrees, so pair it with the commands above.

Sources

• OpenAI: Scaling Git at OpenAI (2 November 2026)
• Anthropic: Redesigning source control at Anthropic (13 October 2026)
• GitHub: Building Git infrastructure for agent-scale development (6 October 2026)
• GitHub Octoverse 2026 (28 October 2026)
• Git documentation: partial clone, sparse-checkout, worktree, backfill, scalar, maintenance
• actions/checkout and GitHub merge queue docs