Scion news: gitai v0.4.0 and the October release timeline

Official Scion: the availability answer is unchanged

Anthropic’s engineering article was published on October 13 and still labels its update October 15. The update credits earlier source-control work, including Piper and Sapling’s Mononoke. The article describes an internal system and links no public distribution.

A newly published discussion of that article is not itself a new software release. For the background and the distinction between similarly named projects, start with What is Anthropic Scion?.

Community releases since our previous check

The latest entry on gitai’s release list is v0.4.0. Here is the sequence after the v0.2.0 snapshot previously documented on this site. Dates are release publication dates in UTC; v0.3.1 was published on October 23 in China Standard Time.

v0.4.0: repository creation and tighter reference handling

Operators can now create repositories through graft repo create or the Go SDK. The release also makes branch lookup exact across operation RPCs, preventing a similarly named tag from standing in for a branch. Agents are barred from writing the server’s refs/graft/ references in every mode.

The notes also describe fixes for maintenance on busy reftable repositories. Upgraders should review changed error codes and remove SSHUploadArchive from any agent_rpcs configuration; that entry now prevents server startup. v0.4.0 itself requires no data migration.

v0.3.1: Windows clients and a landing correctness fix

The CLI and Go SDK gained Windows support; the release notes keep the server Linux-only. This does not establish support for a native Windows server, and we have not tested the new clients.

UserLand now reads the named branch exactly instead of allowing Git revision lookup to resolve a tag or remote-tracking reference. The release also reduces disk flushes on the landing path. Its reported speed improvement comes from a particular WSL2, SQLite and file-bucket setup; it does not predict another deployment’s throughput.

v0.3.0: storage recovery and verified conflict proposals

The storage core gained checkpoints, garbage collection and hydration improvements. For deployments using the storage core, the release requires stopping and upgrading every node. The first upgraded node migrates the database; older v0.2.x nodes cannot use it. Reverting requires restoring both the database and bucket from backup.

Model-generated conflict resolutions are proposals unless verify.command passes on the exact resulting tree. This makes your own tests part of the acceptance path; model agreement alone does not prove correctness. The release notes identify unverified areas, including cloud buckets, nodes on separate hosts and real power-loss recovery.

What this changes for an evaluation

Our macOS quickstart remains a historical test of revision 1d8dc0e on October 16. Its successful build and two-client experiment do not validate v0.4.0 or the newer platform claims.

For a fresh trial, pin the release you intend to evaluate, read every intervening upgrade note, and use a disposable repository. Check allowed and denied writes, final file contents, restart behavior and recovery from a failed change. Keep those results separate from upstream benchmark claims.

Common questions