CarterT27/scion

Scion is worth watching if you operate many short-lived agent or CI jobs against a large monorepo; it is not a drop-in Git replacement and the README itself scopes v1 to one monorepo and Unix clients. Read the limitations before investing setup time.

The problem

A coding agent or CI job usually needs a handful of files and a place to record a commit. With Git, that often means cloning more history and objects than the job touches, and then pushing back after the work is done. Scion aims to change that: the client fetches only the paths in its sparse scope, while commits, rebases, merges and landing happen through server APIs rather than a separate push. The result is a working copy restricted to the job's paths, with history and diffs available through gRPC queries instead of a local clone.

What's different

Scion is a Rust reimplementation inspired by Anthropic's "Redesigning source control" post, not Anthropic's code, and the README says so explicitly. Its main structural choice is to keep history and expensive operations on the server: commits are recorded through an API, changesets store file deltas against the first parent, objects use BLAKE3 identifiers and zstd compression, and the daemon caches fetched objects across jobs. History queries such as diff, log, blame and merge-base run over the wire instead of requiring a local repository. For migration, a one-way Git importer preserves history and records Git-to-Scion mappings.

The trade-off is operational weight. Running the service requires CockroachDB, an S3-compatible bucket, TLS certificates, an Ed25519 signing key and an access policy, all described in the configuration spec. That is a lot of moving parts compared with a Git server, and the README does not describe a lightweight single-node alternative. The benchmark material is also first-party: it compares Scion with Git on synthetic workloads and on a real repository, but through the project's own runner and fixtures. Those numbers describe particular local measurements, not a production guarantee.

Who should try it

Good fit: a platform or developer-productivity team running an internal monorepo who wants to experiment with server-side history and sparse job checkouts for CI or agents, and who already runs CockroachDB and S3-compatible storage. The Unix-client and single-monorepo scope matters less in that setting.

Poor fit: a team that just wants faster Git checkouts, or anyone looking for a drop-in replacement for a GitHub or GitLab workflow. The v1 scope excludes regional cache servers, virtualized checkouts, filesystem-watcher status and copy detection; the daemon's cache is a per-node library, not a regional service. Windows is not a supported client target.

Requirements and limitations

Building needs Rust, pinned to 1.98.0, plus protoc. Running the server is the bigger commitment: CockroachDB, an S3-compatible bucket, TLS, a signing key and an access policy need to be configured before the first login. Ongoing operation means keeping those dependencies healthy and managing the daemon cache.

The README states that production throughput and resilience at Anthropic's scale have not been established. The included benchmarks are local measurements made on 2026-10-14, and the Git differentials and conformance tests exercise correctness rather than scale. The default test suite avoids a real database by using in-memory storage and loopback services; the external Docker Compose route is a separate step for CockroachDB and MinIO coverage.

HotRepo's take

Scion was 12 days old with 247 total stars when HotRepo recorded it at #23 on the NEW-REPOSITORY board (rust) on 2026-10-27. That is a single dated snapshot, not a daily growth series, so trend persistence cannot be judged. Before spending time, verify the monorepo and Unix-only scope against your own environment and read the server configuration spec, since that is where the operational cost lives.

Project source and documentation