open_scion vs Anthropic Scion

Three names, three different starting points

The feder-cr/open_scion README identifies the project as independent and describes version 0.1.0 as its first public release. Its internal components use the name Graft. The source is available for inspection and local experiments, while interfaces may change before 1.0.

Anthropic’s engineering article describes its internal Scion and links no public distribution as of 16 October 2026. Its October 15 update adds context about earlier work, including Piper and Sapling’s Mononoke server. Public design inspiration does not imply shared source code or implementation equivalence.

What the community project adds to Gitaly

The architecture documentation describes sparse workspaces served by object RPCs, server-side history queries, an ordered changeset stream, and a landing operation that rebases or merges against the current branch tip. Optional cache tiers reuse immutable objects. These are documented project capabilities, not results from an Anthropic deployment.

Gitaly supplies the underlying Git repository operations. Graft adds services and can perform access checks without a GitLab installation in standalone mode. That makes a local server experiment possible; it does not supply the complete GitLab product.

Similar principles do not mean identical storage

Anthropic describes a custom changeset model without Git packfiles. open_scion keeps Git underneath. Its optional storage core records reference changes in SQLite or PostgreSQL and places content-addressed Git packs in object storage. Local repositories become rebuildable caches in authoritative mode.

The storage core is off by default. Shadow mode mirrors writes while local Git remains authoritative; authoritative mode moves the commit decision to the database. These are distinct configurations. A quickstart using the default mode cannot establish the behavior of a database-backed, multi-host deployment.

Read the limits before planning adoption

The limitations document says the project does not reproduce Scion’s private internals. It also describes a sparse client rather than a full Git CLI replacement: commands requiring a complete local object graph need a normal Git clone. A web hosting interface and CI platform are outside its scope.

Documentation deserves the same scrutiny as code. The README claims multi-node test coverage, while the limitations page still says multi-node behavior is untested. Treat that discrepancy as an unresolved documentation question. Neither statement establishes production readiness for your workload.

A small local demonstration can confirm particular commands and outputs. It cannot validate high availability, large-repository performance, security isolation, or the speedups Anthropic reported for its own infrastructure.

Choose a repeatable experiment

Our recommendation is to start with a disposable repository and a pinned source revision. Record the operating system, toolchain, configuration, commands, and resulting history. Have two workspaces change separate files, then introduce a deliberate conflict. Check the final content and server log instead of treating a successful process exit as sufficient evidence.

Keep an ordinary Git workflow as the baseline. Git already offers partial clone and sparse checkout; test whether those solve the observed delay before taking on a new service. Compare complete tasks under the same conditions, and publish failures alongside successes.

Common questions