Git is the default way software teams track code. Scion is the system Anthropic built to replace it inside its own monorepo. The two are built on opposite assumptions about who is using them, and that difference explains almost every other design choice. This comparison uses Anthropic's engineering post as its only source for Scion. All Scion numbers are Anthropic's own and we have not verified them independently. For the news and the background, read our Scion launch coverage. This post is the side-by-side.
TL;DR: Scion vs git at a glance
| Question | Git | Scion (per Anthropic) |
|---|---|---|
| Core assumption | Any clone may be offline and must stand alone | Clients are almost always online |
| Where work happens | On each client, with a full copy of history | On the server, which answers queries and creates commits |
| Unit of change | Commit pointing at a tree | Changeset: files changed from the first parent plus content pointers |
| History and blame | Computed locally from the full history | Server-side, backed by precomputed "derived data" |
| Checkout | Full or partial clone, packfiles | Sparse or virtualized, objects fetched on demand |
| Branching | Cheap local branches and refs | Refs discouraged except for main or release branches |
| Offline work | Fully supported | Not a design goal |
| Availability | Public, universal | Internal to Anthropic |
| Best for | Almost every repository | A huge monorepo written to mostly by agents and jobs |
The core difference: who is the client?
Git was designed so that every copy of a repository is identical and self-sufficient. That is why it works on a plane, why a developer can commit locally for days, and why a repository survives the loss of its host. The cost is that every clone carries the whole history, and operations like diff and blame run on the client.
Anthropic's post makes a pointed observation. It was using git as a centralized system with one authoritative copy, while almost all of its clients were agents and CI jobs that are online by definition. The properties that make git excellent for offline human work were working against it at that scale. Scion starts from the opposite premise: clients are always online, so they should ask the server instead of holding everything.
Design differences, one by one
Commits and changesets
A git commit points at a full tree snapshot. A Scion changeset is an entry in a write-ahead log that stores the list of files changed relative to its first parent, plus content-addressed pointers to compressed file contents in blob storage. Anthropic says changesets are created on the server and are available everywhere instantly, and that moving a ref is a separate compare-and-swap operation. The practical effect is that creating a commit, rebase or merge happens server-side, so there is nothing to push.
History, blame and derived data
Because a changeset records only what changed, answering "who last edited this line" needs extra structures. Anthropic calls them derived data: file blame, path history and skip lists for the commit graph, each defined recursively from the values for a changeset's parents. In git, you get this by walking history on a full or partial clone. In Scion, the server holds these structures, and the post says new types can be added without changing the client.
Checkout and the working copy
Git fetch protocols negotiate what the client already has and often return large packfiles. Scion's client, scn, does not tell the server what it has. Starting from a root tree, it checks a local store for missing trees, requests them recursively, then repeats for blobs. Every request is for an immutable object, so any cache can answer it. A node-level daemon, regional caches and an authoritative server answer the same requests in strict tiers. Anthropic says each tier keeps a hit rate above 99% and that no fully materialized copy of the repository exists anywhere, even on the server.
The working copy is optional and sparse: a CI job that only needs the diff to a merge base can ask the server for it and never check out files.
Branches and refs
Git encourages many cheap branches. Scion discourages refs except for main or release branches, because global state that every server must agree on is a scaling problem. For people used to feature branches, that is a real change in workflow, handled in Anthropic's world by its own code review system and change requests.
Scale and operations
Anthropic says everything in Scion scales horizontally, with no packfiles and so no repository maintenance. It contrasts that with a git setup that needed several hundred internal mirrors at peak. The company reports Scion infrastructure is 200x smaller in CPU and memory than the git mirror fleet, checkouts are two orders of magnitude faster, and CI gained 25% in CPU capacity.
The problem each one solves
| Pressure | Git's answer | Scion's answer |
|---|---|---|
| Big history | Shallow clones, partial clones, mirrors | History lives on the server and is queried |
| Big working copy | Sparse checkout | Sparse or virtualized by default |
| Many concurrent writers | Branches, merge queues | Cheap lock-free server-side commits |
| Automated jobs | Clone the repo in each job | Query an API, often with no local repository |
| Offline use | Native | Not supported by design |
Anthropic notes it used git's own tools, including shallow clones, sparse checkouts, promisor remotes and seeds in blob storage, before building something new. At its peak it ran several hundred internal mirrors, and seeds drifted from the tip of main, which made diff and blame on partial clones harder to manage.
A worked example: one change, two systems
Imagine an agent finishes a small fix and needs it merged, tested and visible to other jobs.
In git. The agent has a clone, either full, partial or sparse. It commits locally, pushes a branch to the host, and a pull request or merge queue takes over. Every other job that wants the result fetches it, and each fetch negotiates what the client already has. The host, or one of its mirrors, serves it. At small scale this is invisible. At the volume Anthropic describes, mirrors and seeds drift from the tip of main, which is why diff and blame on partial clones needed ever more care.
In Scion. The agent asks the server to create the changeset. Nothing is pushed, because the commit already exists on the server and is available everywhere instantly. Another job that needs the diff to a merge base asks the server for exactly that, and may never check out a file. A job that does need files fetches immutable objects through the daemon and regional caches, so repeat reads are served from memory.
The same change takes fewer steps and moves less data in the second model. That is the point of the design, and also why it only pays off when almost every client is an always-online job.
What you give up with Scion's model
- Offline work. A system that assumes always-online clients cannot serve a developer on a train.
- Independence. A git repository can be moved between hosts, forked and archived. A server-centric system ties you to its server.
- Ecosystem. Git has editors, hosting services, CI integrations and decades of knowledge around it. Scion has one internal user base.
- Portability of habits. Workflows built on local branches and rebases change when refs and commits behave differently.
When git is still the right choice
Anthropic says directly that git's decentralized design is right for the vast majority of repositories. Use git when your team is humans working in ordinary repositories, when offline work or open collaboration matters, when you rely on hosting and CI integrations, or when your repository is large but not extreme. Before switching anything, try git's own tools for large repositories: partial clone, sparse checkout and a merge queue. They solve most scale problems without leaving the ecosystem.
When a Scion-style design starts to make sense
The conditions Anthropic describes are specific: a monorepo with a huge history, tens of millions of daily checkouts, and clients that are mostly agents and jobs. If your bottleneck is that automation clones your repository over and over, a service that answers repository questions through an API is the idea to borrow, even if you do not adopt a new version control system. Our monorepo primer covers why those repositories strain tooling, and our git beginner's guide covers the model Scion departs from.
Prior art: Scion is not from nowhere
Anthropic credits earlier systems, notably Google's Piper and Meta's Sapling, for the server-centric approach. The idea of a large-repository system with a service in the middle is not new. What Anthropic adds is a description of how the pressure changes when agents write most of the code, and a design built around that. The company also says Claude helped build Scion, including rewriting an early ingestion pipeline that it reports used 20x less memory and ran 4x faster.
Caveats
- Every Scion figure here is from Anthropic's post and unverified.
- Scion is internal. There is no public release in the text we read.
- It leans on Google Spanner and cloud blob storage, so a team on other infrastructure would need different building blocks.
- The post describes a success, and says little about failed approaches.
Bottom line
Scion and git are not rivals for your next project. Git is the right tool for almost everyone. Scion is a description of what happens at the far edge, when agents turn a monorepo into an always-online, high-volume service. The useful lessons are architectural: let the server answer questions, keep checkouts sparse, and avoid global state. For the third option in this space, see our three-way comparison with Cursor Origin.
Related reading
- Anthropic Replaced Git With Scion: the news and numbers
- Scion vs Git vs Cursor Origin
- Server-centric vs distributed version control: a decision guide
- What are monorepos?
- What is git? A beginner's guide
- Claude Code vs Cursor vs GitHub Copilot
Scion details are from Anthropic's October 13, 2026 engineering post. Figures are the company's own, and this comparison will be updated if Anthropic publishes more.