When agents send changes faster than git can land them

TL;DR

• GitHub and Anthropic have each described where git’s full-copy design stops fitting under coding agents. At GitHub the limit is merges updating one branch pointer. At Anthropic it was CI reads outgrowing its mirrors.
• Repository size has fixes that buy time. The write to one branch can be batched, not avoided.
• Start with merge batching, so several changes land as one update to main. Drop the queue’s lock if tests can’t keep up with arrivals. If batches that have passed their tests still wait to land, raise it with your host.
  

An agent in a tight loop commits after nearly every step, and each push triggers many CI fetches. Git was built for the opposite shape of work: people, often offline, each with a complete copy of the repository. That design has a ceiling, and hosts share it because they keep full copies too. At GitHub, merges contend for one branch pointer, and the ceiling shows first as slower pushes and merges. Anthropic hit it on the read side, when the copies serving its CI could no longer keep up.

Pushes, merges and checkouts in 2026

GitHub’s numbers are platform-wide. Monthly pushes grew from 0.69 billion to 3.35 billion in a year, pull-request merges nearly fourfold, and commits in September 2026 reached 7.38 billion, over five times the year before.

Anthropic’s numbers come from a monorepo. Merges rose from about 2,500 a day in May 2026 to more than 30,000 a day in September, one every three seconds. A compressed checkout of the latest code was over 25 GB, and CI checked out code about 25 million times a day, which fetched naively would be over 600 PB a day. Hundreds of git mirrors and snapshots kept in cloud storage carried the load until the merge rate left the snapshots behind the latest commit and the repository outgrew the mirrors’ disks or memory.

Three limits on a git host

• One hot ref. Trunk-based development and merge queues send every merge to one branch pointer, a ref, where merges contend. Even a git server with only one copy has the same limit. With git’s reftable backend, planned as the default for new repositories in Git 3.0, the whole repository allows only one ref update at a time, so pushes to agent branches wait in the same line as main.
• A moving tip, fetched thousands of times a minute. An uncached fetch has the server compress the requested objects into a packfile, the most expensive thing a git server does. GitLab’s pack-objects cache reuses only identical requests, so frequent changes to main leave it less to reuse.
• Reads coupled to writes. GitHub keeps five copies of every repository by default, and every copy takes part in every write, so a push finishes only when its slowest copy has. Each copy added for reads slows every write, and at GitHub’s busiest repositories this becomes a ceiling.

Repository size is a separate problem, with fixes that buy time. Dropbox’s monorepo went from 87 GB to 20 GB in a repack GitHub ran on its servers. The write to one branch has no client-side fix, so the ref is the condition to watch.

What Anthropic built and GitHub is building

The two designs share a shape. Scion replaces git at Anthropic, while GitHub keeps git and rebuilds the storage under it. The authoritative copy lives in durable storage (Spanner and cloud storage for Scion, Azure Blob Storage for GitHub). Reads come from caches (Scion’s three tiers, GitHub’s caching read workers). The one step that needs agreement between servers is the ref update, and Scion discourages refs beyond main and release branches.

• Scion assumes agents and jobs are online, so they fetch trees and blobs on demand and never say what they already hold. Objects never change, so any cache can answer.
• In the fleet, read requests for trees and blobs go first to scion-daemon, one per node, which holds objects for every job on that machine.
• A miss moves up one tier at a time, from the daemon to the regional scion-cache and then to scion-server. Each tier serves more than 99% of its requests from its own cache. Requested objects return along that path to the client.
• Writes go straight to scion-server. Commits, rebases and merges are made on the server, so agents have nothing to push. Creating a commit takes no lock and no coordination between servers.
• Moving a ref such as main is separate from creating a commit. The server points the ref at a new commit with a compare-and-swap on one Spanner row.
• The server reads missing objects from Spanner or cloud storage and writes new data there. No full copy of the repository is assembled anywhere, not even on a server.

Anthropic’s results for its own fleet: CPU and memory 200 times smaller than the mirrors it replaced, checkouts in seconds instead of minutes, and a 25% CPU capacity gain in CI. GitHub’s design reached up to 35 times the write throughput in an internal benchmark whose workload is not described. Scion stays inside Anthropic, and GitHub is still putting its own in place.

What happens to the merge queue

A merge queue holds each change until its tests pass against main, so changes that pass on their own can’t break main together. The more changes agents send, the more that waiting costs, and teams handle it in one of three ways.

• Serial queue with a global lock. Each change is tested against the current tip of main and lands only if it passes, one at a time and in order, so every commit on main has passed. At most one change lands per test run.
• Batched queue. Several waiting changes are combined and tested together, and if they pass they land as one ref update. Only the batch’s end state is guaranteed to pass, not each change inside it.
• No global lock. Each change lands on main without waiting for a global lock, then is tested after the merge and again before deploy. Changes made at the same time can conflict once both have landed. Anthropic claims that Claude typically fixes those faster than people spot them.

Anthropic gave up the merge queue’s global lock, which it could not make work when hundreds or thousands of changes arrive during a test run. PostHog went the other way. With agents opening 70% of its monorepo PRs by July, PRs that passed on their own were breaking main when merged together, so it started work on a merge queue and selective tests.

Before Anthropic’s step, try a batched queue, because giving up the lock is worth its conflicts only once batched tests cannot keep pace.

Implications

Watch the time between a batch passing its tests and its merge landing. Check your queue’s batch settings first, since they can hold tested changes while waiting for more to arrive. If you run your own mirrors or snapshots, watch how far they lag the latest commit.

Then make CI cheaper. Jobs that only need a diff or a blame can ask your host’s API instead of checking out the repository, as Scion’s jobs ask its server, and jobs that need files can fetch just the parts they use with partial clones and sparse checkout. Next, turn on batching in your merge queue. If even batches cannot keep up, move testing to after the merge and before deploy, as Anthropic did, unless every commit has to pass CI on its own.

Takeaways

• If merges start queuing as agents add volume, turn on merge batching and have agents push less often instead of after every step. If batches that have passed their tests still wait to land, raise the delay with your host.
• If CI fetches slow down as merges speed up, main is probably changing too often for caches to help, so ask your host about better caching. At Anthropic’s scale, 25 million checkouts a day, the answer was its own version control system.
• Most teams are not near these limits yet. Anthropic expects few organisations to hit them in the very near term, but more within six to 12 months. Don’t conclude your repository is “too big for git” until you have tried partial clones, sparse checkout and a host-side repack.