Who Gets a Full Copy?

Anthropic built a version-control system that assumes its clients will stay connected. GitHub is rebuilding its Git infrastructure while promising that developers will not have to change how they work.

Both projects respond to the same pressure: agents are producing and reading code at a rate that infrastructure designed around human activity did not anticipate. The revealing difference is not how many commits each system can accept. It is who gets to keep a copy of the repository.

A normal Git clone is deliberately extravagant. By default, it brings down the project's files and nearly all of its history. The official Git book describes every clone as a full backup. A developer can inspect old changes, make new ones, create branches, and commit while the server is unavailable. The repository travels with the person.

That property is expensive when the client is not a person with a laptop.

Anthropic says its main branch history approached 100 GB while a compressed working copy exceeded 25 GB. Its continuous-integration and research systems performed roughly 25 million checkouts each day. By September, the company was merging more than 30,000 changes a day, up from about 2,500 in May.

The company responded by replacing Git for its monorepo with Scion, an internal client-server system built around a different first assumption: nearly all of its clients are agents and jobs that are online by definition.

Scion's server creates commits, performs merges and rebases, and answers questions about history and blame. Clients maintain bounded caches and request only the trees and files they need. A job can ask for a diff without materializing a working copy at all. Anthropic reports that the resulting infrastructure uses 200 times less CPU and memory than the Git mirrors it replaced, makes checkouts two orders of magnitude faster, and returned 25% of continuous-integration CPU capacity.

For that environment, refusing to send every client the whole past is not deprivation. It is an accurate description of the client. A short-lived agent does not need to carry the institution's complete memory into a sandbox that may disappear after one task.

GitHub is meeting a related load at a different boundary. In September, developers and agents made 7.38 billion commits on GitHub, more than five times the number a year earlier. The busiest repositories now have thousands of actors writing concurrently while continuous integration and code scanning multiply each push into many more reads.

GitHub's new architecture also separates storage from compute. Durable repository data moves into object storage while lightweight workers serve and cache reads. Its newest bridge design serializes writes per reference instead of locking an entire repository, so agents working on different branches do not wait for one another.

The machinery changes. The public contract is supposed to hold.

GitHub says the redesign must preserve branching, review, merge, history, branch protection, audit logs, and the workflows developers already trust. It is rebuilding underneath a population that includes agent fleets, regulated companies, volunteer maintainers, and a student opening a first pull request. Those clients do not share one relationship to the server.

The two projects are not really arguing about whether Git is good. They are answering to different constituencies.

Anthropic operates a private monorepo where the company controls the network, clients, identity system, and migration. It can say that the useful unit for most clients is a sparse working set plus server access. GitHub hosts other people's repositories. Its infrastructure can become more centralized internally while an external clone remains something a developer can take elsewhere.

That distinction makes agent-ready less like a universal destination and more like a design disclosure.

An always-online agent benefits when the server can answer a narrow question without delivering a century of project history. A person may value that same history for reasons that do not show up in checkout latency: working through an outage, searching without asking a remote service, preserving a project after a host or employer changes, or understanding how the current state came to be.

Not every repository needs every property in its strongest form. Git already supports partial clones for working with large projects without downloading every object. Most teams also depend on server-side permissions, review rules, issue history, and continuous integration that a clone does not contain. A full local copy is neither complete institutional independence nor a sacred ritual.

It is still a form of possession.

When infrastructure is redesigned around agents, the useful review should therefore include more than throughput. Which clients are assumed to be temporary? Which ones are expected to retain history? Can a person export the authoritative record, work during an outage, inspect the past without a live permission check, and restore the project somewhere else? If those capabilities move to the server, who operates the server and what promise replaces the copy?

The answers can differ between a private monorepo and a public forge. That is the point. Scale does not make one architecture inevitable. It makes the imagined user inside the architecture easier to see.

Agent traffic is forcing old systems to declare which of their properties were implementation baggage and which were part of the bargain. Before the next repository becomes a thin window onto a distant service, ask the practical question in the title: who still gets the full copy?