Redesigning source control at Anthropic

What it claims

Scion is not released and Anthropic says it is not suitable as a general git replacement. The actionable content is the design: what broke with git at this scale, and which Scion ideas Anthropic suggests git servers and forges adopt. The scale that forced the change was about 100 GB of main-branch history, a compressed working copy over 25 GB, and about 25 million CI checkouts per day before counting dev environments, agent sandboxes and research jobs. Fetched naively, that would be over 600 PB/day of git traffic. Shallow clones, sparse checkouts, promisor remotes, blob-storage seeds and several hundred git mirrors only bought time. Seeds drifted further from main, and diff and blame on partial clones got harder to keep working. The design draws on Google's Piper and Meta's Sapling.

How it works

• Changesets, not trees. Each write-ahead-log entry lists the files changed against the first parent, with content-addressed pointers to compressed blobs. Commits, rebases and merges all run server-side, with no packfiles, locks or cross-server coordination. Refs are discouraged except main and release branches. Moving a ref is a compare-and-swap on one Spanner row, separate from changeset creation.
• Derived data. Blame, path history, commit-graph skip lists, copy-detection and path-search indices are each defined recursively from the parent changesets. Each type can be computed eagerly or deferred. The client never sees these structures, so they can change without client changes.
• Want-only fetch. The client never tells the server what it already has. It starts from a root tree, requests the trees it is missing recursively, then the blobs. Every request names an immutable object, so any cache can answer it. Fetches are resumable because there is no single multi-GB pack. Sparse and virtualized checkouts need no special support: the client just doesn't ask for unwanted trees.
• API-first. Every query the client uses is also exposed as an API, including diffs, merge bases and some writes. Many CI jobs need no checkout at all, and the automated bisect and revert pipelines depend on this.

flowchart LR
  C[scn client] -->|socket| D[scion-daemon<br/>per node, from snapshot]
  D -->|miss| K[scion-cache<br/>regional, in-memory]
  K -->|miss| S[scion-server]
  S --> P[(Spanner / cloud storage)]
  D -.->|forbidden: skip tier| S

All three tiers serve identical RPCs, so the client is unaware of the topology. Even so, tiering is strictly enforced so that a regional cache failure cannot overwhelm the scion-servers. The caches stream objects in the daemon's on-disk format, with no missing-object computation or delta compression.

Evidence

• Each cache tier has a hit rate above 99% and holds no long-lived state.
• Scion uses 200x less CPU and memory than the previous git mirror fleet.
• Checkouts take seconds instead of minutes, which gave CI a 25% CPU capacity win.
• An early Claude Mythos Preview rewrite of the handwritten git-to-Scion ingestion pipeline used 20x less memory and ran 4x faster, while preserving ordering invariants.
• Seven people built Scion, the Antique code review tool and about six related systems, and migrated in five months while daily merge volume grew 10x.

All numbers are self-reported, with no benchmark methodology given.

How to use it

There is nothing to install. Anthropic's suggestions for git:

• Make git servers architecturally different from clients.
• Have forges expose comprehensive server-side RPCs, possibly standardized so the git client can call them.
• Revise the negotiation protocol.
• Make sparse and shallow features compose.

Process lessons the post states:

• Engineers mostly review the intent of each change rather than every line.
• Engineers often have to say "no" to agents. Examples: agents brute-forced merge times by reading the commit log linearly, and agents over-engineered validation in response to adversarial review.
• Each component gets a "superfan" Claude in Slack that watches telemetry and logs, alongside conventional alerts.
• A merge queue with a global lock could not be sustained, so testing moved post-merge and pre-deploy. Concurrent changes can conflict, and Claude fixes them.

Limits

• Requires always-online clients. Clients can compute very little offline.
• Only for very large repos. The authors say it makes sense only for enormous monorepos, with tens of thousands of engineers or agent swarms.
• Depends on unusual token spend. It relies on internal token spend most businesses would not accept.
• Bespoke surrounding stack. Adoption would mean migrating the whole lifecycle, because Scion needs its own code review, search and CI, and these are bespoke.
• No public release planned.
• Post-merge testing allows conflicts. It accepts conflicting concurrent merges.