Scion solves an Anthropic-sized problem
Anthropic reports that its merged code changes grew from about 2,500 per day in May 2026 to more than 30,000 per day in September. Its main-branch history approached 100 GB. A compressed working copy exceeded 25 GB. CI performed about 25 million checkouts per day. Anthropic says naive fetching would have produced more than 600 PB of Git traffic per day.[1]
The company built Scion with a seven-person team and moved its monorepo in five months. Those numbers explain the decision. They do not make Scion a general replacement for Git. Most teams do not have this workload, and Anthropic has not published Scion as a product that readers can install or test.
Architecture starts with the workload. A large merge count does not answer who should hold the source.
The client stopped pretending to be a server
Git gives each clone enough repository data to compute history, diffs, blame, and checkouts offline. Scion makes a different trade. Its server creates commits, merges, and rebases. The client keeps a bounded object cache, materializes working files, watches the filesystem, and asks the service for the rest.[1]
Scion stores each changeset as a write-ahead-log entry with changed paths and content-addressed file data. It builds path history, blame, and commit-graph indexes as derived data. The service can compute those indexes when needed without exposing their layout to clients. CI jobs can request a diff or history answer through an API without creating a checkout.
This is a custody transfer. It cuts repeated repository materialization. It also makes network reachability and service recovery part of ordinary source-control work. Anthropic says most Scion clients are agents and online jobs, so offline work was not a governing requirement. That condition must be measured, not inherited.
Try the smaller moves first
Git worktrees let several working trees share one repository. Each linked worktree has its own checkout and administrative metadata. A throwaway detached worktree can isolate an experiment without cloning the object database again.[3]
Jujutsu workspaces also attach several working copies to one repository. Each workspace has its own working-copy commit, while the repository and operation log remain shared. Jujutsu warns that commands run in one workspace can make another working copy stale, so the coordination cost is visible rather than absent.[4]
These tools do not reproduce Scion's server architecture. They test a cheaper question first: can shared objects and separate working directories remove enough checkout waste? Sparse materialization, object caches, and a history-query service deserve the same trial before a full custody transfer.
A service-first repo needs an exit drill
Measure clone bytes, materialization time, history-query latency, cache hit rate, and peak concurrency for developer machines, CI, agent sandboxes, and read-only analysis separately. One mode may not fit all four.
Then cut the network. Record which operations still work, how queued writes are recovered, how review state survives, and how long it takes to export and rebuild the authoritative repository elsewhere. A fast online commit path is an operating result. It is not an exit plan.
Scion is strong evidence that source control can move toward query services and on-demand files under extreme pressure. The next useful step for everyone else is a workload trace and a failure drill, not a migration announcement.