Scion (scn) vs Git: when source control becomes a service

What Anthropic built

Scion is Anthropic’s internal version-control system; scn is its client. Its October 2026 engineering announcement describes moving source-control operations to a service for an unusually large monorepo and an agent-heavy workload.

Clients are designed to stay online. The server creates changesets and performs history queries, merges and rebases. Clients keep a bounded object cache and materialize requested files. A changeset records changed files relative to its first parent, with pointers to stored contents; additional indexes support queries such as file history.

Anthropic reports lower infrastructure demands and faster checkouts, but those are results from its own environment, not a benchmark we reproduced. The company explicitly says Scion is unsuitable as a general Git replacement and that adoption would require replacing surrounding development tools. This announcement is not a public installation guide. We have not run Scion.

What you give up when work moves off the laptop

In a normal full Git clone, the local object database supports history inspection and commits without contacting a hosting service. A commit records a project snapshot through a tree, along with its parents and metadata. Git can reuse unchanged objects; it does not copy every file’s contents afresh for each commit.

That local capability is useful when the network fails, while travelling, or when trying a change you are not ready to share. Publishing work to a remote is a separate step. Git’s model also allows repositories to exchange work without one mandatory central provider.

Full clones are not the only configuration. A shallow clone truncates history. A partial clone can omit objects initially and obtain them later. Neither should be described as a complete offline repository. Sparse checkout is different again: it controls which tracked paths appear in the working directory, rather than being a synonym for downloading less history.

I think online CI workers and a developer’s laptop deserve separate requirements. A worker might benefit from fetching less. A developer might value keeping enough local history to investigate an incident during an outage. Treating both as identical clients hides that trade-off.

Work through a test-selection job

Consider a proposed workflow, not a measured result: a documentation check should run when a change affects the docs directory. It only needs a changed-path list to make that decision. It does not need to render the website merely to decide whether a render is necessary.

I recommend defining the comparison before choosing its implementation. Which base revision is authoritative? Is the job examining a proposed change or the result of merging it? How should deletions and renames affect the selection? What happens if the service cannot answer?

The Git diff manual distinguishes comparing working files, commits and a commit against a merge base. Those answer different questions. Replacing a local command with an API is useful only if the API preserves the comparison you actually intended.

For this example, I recommend binding the decision to immutable revision IDs, retaining the changed-path result with the job, and running the broader check if selection fails. Skipping a necessary check because the query timed out would trade an infrastructure saving for an incorrect release decision.

A service still needs an operator

Moving computation to a service changes who must keep it available. In my judgement, an evaluation should include outage behaviour, recovery and the ability to export work, alongside checkout speed. Ask which operations stop when connectivity or the service fails, and whether unsubmitted edits remain recoverable.

There is public precedent for specialized source-control infrastructure. Meta’s Mononoke is the server for Sapling. Its public README also warns that the exported implementation omits internal components, including some APIs and configuration documentation. Studying an architecture and adopting a supported product are different commitments.

I recommend investigating the surrounding workflow before migrating repository storage. Code review, access control and release tools must still agree on what a revision means. A working client binary alone is not a migration plan.

What to try while staying with Git

Git already offers ways to narrow what a job receives. The clone manual documents shallow history and object filters. The sparse-checkout manual explains restricting the working tree, including combinations with partial clone. These options affect different layers; choose them for the data the job needs rather than enabling every restriction at once.

For a job that builds only one area, I prefer to test a smaller working tree first. For a job that needs just a revision comparison, I would investigate whether the existing hosting service can provide it. For repeated cold starts, I would measure cache reuse before proposing a new version-control system.

Measure the complete job: repository preparation, dependency installation, test execution and waiting for shared infrastructure. Record the starting revision and cache state. If fetching is quick but dependency installation dominates, changing source control addresses the wrong part of the delay.

I recommend replacing a measured bottleneck rather than a familiar tool that a different organisation outgrew. The useful design question is how much repository data and computation each consumer actually needs—and where that work belongs.