Scion: committing and landing on the server, with no clone

The problem

Once there are many coding agentscoding agentAn AI program that reads and edits code and runs commands for a developer. Claude Code and Codex are examples., the rate at which changes merge into a repository becomes the bottleneck. Anthropic published “Redesigning source control at Anthropic” on its engineering blog on October 13, 2026. According to that article, merges per day went from about 2,500 in May 2026 to over 30,000 in September. Full clones and the merge queue broke down under tens of thousands of changes to the same branches.

According to the Git documentation, clone copies the whole repository into a new directory, and the --depth, --filter and --sparse options reduce how much it copies. GitHub offers a feature called the merge queue. According to its documentation, a repository administrator can require the queue in a branch protection rule. Then pull requestspull requestA request to merge the changes on one branch into another. Other developers review and approve it. join the queue instead of merging directly. GitHub creates a temporary branch for each queued pull request. The branch combines the latest target branch with the requests ahead of it. GitHub runs the required checks and merges only what passes. That keeps incompatible changes from being merged together even on a branch that receives changes constantly. In exchange, merges happen in queue order, one group at a time. The same article says this does not fit agent scale. Hundreds or even thousands of changes can merge while tests are still running, so the state that was tested soon differs from the actual branch. The industry standard is a global repository lock on the merge queue. Anthropic could not make it work at that scale either. Anthropic instead invested in post-merge and pre-deploy automated testing. The trade-off is that concurrently merged changes can conflict, and the article says Claude can typically fix these conflicts faster than humans can even identify them.

How it solves it

Three public implementations of that design appeared within three days of Anthropic’s article. Today’s pick is Scion, which Carter Tran wrote from scratch in Rust. The client does not clone the repository. It fetches only the files under the paths it needs. Server APIs handle commit, rebase and merge. They also handle the final step that puts a change on the branch, so there is no push step. Scion calls that final step land, and it uses no merge queue for it. A change is first rebased onto the latest commit on the branch. The server then moves the branch to the new commit with a compare-and-swap. It moves the branch only if the branch is still at the version it had at rebase time. It leaves the branch alone if another job got there first. The job that lost waits briefly and retries. The client also asks the server for history, blame and merge bases without a clone. Jobs on the same node share objects through a daemon cache. A one-way importer moves Git repositories into Scion.

What is different

The storage format makes this possible. A changeset records a root-tree pointer and only the file deltas against its first parent. Objects are identified by BLAKE3 hashes and compressed with zstd. Blame and path history are looked up in separate derived indexes. Scion uses CockroachDB and S3-compatible storage instead of Anthropic’s Spanner. The README puts offline work, Git protocol compatibility and two-way Git sync out of scope. It says v1 covers one monorepo and Unix clients only. Regional cache servers and virtualized checkouts are not implemented yet, and throughput at Anthropic’s scale has not been established.

How it was built

• 206 commits over three days from 2026-10-13, all by the maker, Carter Tran. Three of them carry Claude in a Co-authored-by trailer.
• 129,266 lines of Rust in 23 crates. The project has four executables (scion, scion-server, scion-daemon and scion-import) and 1,002 test functions.
• SPEC.md is the design specification. It states that the only external input is Anthropic’s article, and requires contributors not to add material derived from non-public implementations.
• The README reports benchmarks measured on an M4 Pro on 2026-10-14 and includes commands to reproduce them. Other implementations of the same design are open_scion and openscion, both in Go.

Running it

1. Build. rustup downloaded Rust 1.98.0, and the first build stopped for lack of protoc. I used pip’s grpcio-tools in place of protoc. The release build finished in 3 minutes 24 seconds, and the benchmark executable is 35.5 MB.
2. Smoke run. I ran all four scenarios once with 20 files to check that they complete. Git ran clone and sparse-checkout commands. Scion connected to an in-process server on in-memory storage.
3. 1,000 files, 5 runs. Medians, Git → Scion: import 352.4 → 111.9 ms, full checkout 594.8 → 336.6 ms, sparse checkout 139.4 → 21.7 ms, one-file commit 35.5 → 27.2 ms.
4. 10,000 files, 3 runs. Import 4,254.8 → 1,324.7 ms, full checkout 5,245.2 → 770.8 ms, sparse checkout 221.3 → 100.0 ms, commit 233.8 → 198.9 ms.
5. Difference from the README. The README says that on the M4 Pro, Git committed faster at both sizes and was slightly faster on the 10,000-file sparse checkout. On today’s 4-core Linux machine, Scion was faster in all four scenarios. The commit gap is under 25%, and the result can reverse on a different machine.
6. Verification. The benchmark code compares the checked-out file contents with the originals byte for byte, and asserts that the sparse checkout fetched exactly two more objects than the file count. The checks passed at both sizes.

$ benchmark 100 5
1000 files, 4096 bytes/file, 5 runs; medians:
| Scenario        | Git (ms) | Scion (ms) |
| import          |    352.4 |      111.9 |
| commit-one-file |     35.5 |       27.2 |
| full-clone      |    594.8 |      336.6 |
| sparse-clone    |    139.4 |       21.7 |

Not checked

• A server on production storage. I had no Docker, so I ran the server only on the in-memory backend instead of CockroachDB and S3-compatible storage.
• Concurrent landing, when several jobs put changes on the same branch at once. The compare-and-swap retry is not in this benchmark. Next time, run scripts/benchmark-scaling.py against a server.
• The 1,002 tests. I did not run them because of the compile time.

Verdict

It works. A 1,000-file sparse checkout was 6 times faster than with Git. The server ran on in-memory storage, though, so these are not production numbers. It is worth a try when you want to experiment with many agents committing to one repository at once and need neither Git compatibility nor offline work. If access must go through the Git protocol, or there is more than one repository, this product is not the right choice. The README puts both outside the v1 scope.

What to take away

• A design article alone can be enough to build a working implementation in three days. Anthropic’s article came out on October 13, and I ran Scion’s benchmark today.
• Re-measure performance comparisons on your own machine. Git was faster at committing on the README’s M4 Pro. Scion was faster on this 4-core Linux box.
• Verify the results inside the benchmark code. This one compares checkout contents byte for byte and asserts the number of fetched objects.
• Put build dependencies on the first line of the README. Today the first Scion build stopped without protoc, and the first open_scion build stopped without libcurl headers.