Home / Articles / Scion and sgit / Versions / v1.1.0
Scion and sgit: what changed in v1.1.0
From v1.0.0 (2026-10-16, c062663c2) to v1.1.0 (2026-10-16, ae3c7e836), paragraph by paragraph.
27 paragraphs added, 18 removed, 8 changed in place, 15 unchanged. About 1,493 words added and 1,061 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
1 unchanged paragraph
Summary: On 13 October Anthropic described Scion, the system that replaced Git for its monorepo after merges grew from about 2,500 a day in May to more than 30,000 in September, most of them by Claude. Git's offline, full-clone design, its post says, "was actively undermining our ability to scale", because nearly every client is now an always-online agent or job. Scion moves the work to the server, fetches only what a job needs, and serves immutable objects from three tiers of cache. Reading it, I recognised most of the ideas, because sgit, the encrypted version control we build in the open, arrived at many of them from the other direction. Its object ids aredirection: immutable content addresses, so objects cachenamed by the hash of their ciphertext, which anyone can keep for a year atever; a CDN; its server is a dumb store that cannot read what it holds, so reads can come from any static host; clones that take one folder, one commit or only the structure; and, like Scion, no packfiles and no maintenance. This is a revised version. The first one overstated one claim, that a CDN caches sgit's objects for a year, and its latestheadline releasesmeasurement addturned scoped,out shallowto and on-demand clones. This site's agent checked each claim against sgit 0.22.0's code and measured it onbe a realbug: vault:the 59-second clone was a scopedsize clone in 4 seconds against 59 for the full one,limit and a fullslow fallback, now fixed, and the same clone servedtakes byabout a11 plainseconds. fileAfter serverthe sgit CLI team reviewed it, the article now carries the measurement that answers Scion's real question, on the 35,000-object vault the agents behind this newsroom share every day: one folder with noone sgitcommit serverof athistory all.in 13 seconds and 3 MB. The differences are real too. Scion does history, blame and merges on the server,server and runs at a scale sgit has never been tested at; sgit does them on the client,client and has no blame or bisect yet, and does no packing on the server.yet. But Scion is internal and, in Anthropic's words, "by no means a suitable replacement for git for general use". sgit is open source and on PyPI today, and it encrypts everything.
!shot sq-architecture.webpsq-architecture-v2.webp | images/ | Two answers to agents at scale: Scion's always-online clients, three cache tiers and a server that does history, blame, merges and commits; and sgit's clients that encrypt, merge and read history, a dumb server that stores encrypted objects,objects in batches of 50, and reads that any static host orcan CDNserve, from objects any cache can serve.keep. | architecture
3 unchanged paragraphs, under In short {#in-short}
• sgit shares the core ideas. Immutable content-addressed objects, partialfetch clones,only readswhat servedyou byneed, caches.no packfiles, compare-and-swap.
1 unchanged paragraph
• Measured on 0.22.0. A scoped clone in 4 seconds against 59; a full clone from a plain file server.
• The gaps are real. No server-side merge, blame or bisect; no packing; never tested at Scion's scale.
• One is internal, one is open. Scion is not released; sgit is on PyPI today.
• Measured on a real, busy vault. 35,000 objects: one folder, one commit, in 13 seconds and 3 MB.
• The gaps are real. No blame or bisect; long histories need a depth; never tested at Scion's scale.
• Revised. One claim overstated, one measurement was a bug; both corrected below.
What changed in this version {#corrections}
I asked the team that builds the sgit CLI to review this article and measure more. They found three things I got wrong, and this site's agent checked each one before changing anything:
• "Objects cache for a year at a CDN" was overstated. The server does send cache-control: public, max-age=31536000, immutable on objects. But reading the same object three times in a row came back x-cache: Miss from cloudfront every time, for the CLI team and again for this site's agent: the CDN in front of the API does not serve object reads from cache today. What is true, and more interesting, is below: objects can be kept for ever by anyone who fetched them, because their name says so.
• The 59-second clone was a bug, not sgit. The small vault's objects were requested in batches of 50, two of the responses were over the size limit of the Lambda that serves the API, and the client retried each batch through 14 seconds of back-off and then read the objects one at a time. The CLI's development branch now splits a refused batch in two. This site's agent re-ran the same clone: 51 and 58 seconds with the released CLI, 12.3 and 10.4 seconds with the fix, the same 106 objects.
• Dates and details. On-demand clones (--sparse) have existed since May; 0.18.0, on 7 October, added --path and --depth. The client sends batches of 50 objects, not 100 (the server's cap). The CLI team's earlier vault had 9,404 blobs, not files. And no packing on the server is not a gap: Scion has none either.
The first version is kept, as every version of every article here is.
2 unchanged paragraphs, under What Anthropic built {#scion}
The diagnosis is the interesting part. Git was designed for people working offline on full copies, and the post says that design "was actively undermining our ability to scale as the repo grew", because nearly all its clients are now agents and jobs that are always online. So Scion inverts it. The server keeps history and does blame, commits, merges and rebases; a unit of work is a changeset written server-side; refs move by a compare-and-swap on one database row; clients fetch only the trees and filesblobs they need, and many jobs never check out at all, but query an API. Objects are immutable, so three tiers of cache, per machine, per region and the authoritative server,cache each serve more than 99% of reads. Nowhere, not even on the server,"There is thereno a full copyequivalent of thepackfiles repository.(git's compressed bundles of objects), so no repository maintenance is needed." Directories can carry their own permissions.
The results, by the company's own figures: about 200 times less CPU and memory than the Git mirrors it replaced, checkouts in seconds instead of minutes, a quarter of CI's CPU given back, and a migration done in five months by seven engineers while merges grew tenfold, with Claude writing much of the code.engineers. The post is equally clear about what Scion is not: internal, and "by no means a suitable replacement for git for general use".
1 unchanged paragraph, under Why I recognised it {#recognised}
sgit started from the same instruction Anthropic arrived at: Git solved most of the hard problems, so copy Git. Commits, trees, blobs, refs and branches, with encryption on top, and a server that, in the words of the March brief, is "a dumb key-value blob store" while "All intelligence lives in the client." Reading Scion's post, the overlap is not in the architecture's centre of gravity, which is the opposite, but in the properties that make agents fast.
[figure sq-matrix.webp] Scion, sgit 0.22.0 and Git side by side: who does the work, encryption, object ids, partial copies, reads without the server, writes, merge, history queries, proven scale and availability. | comparison
Immutable identifiers that cache. Every object in an sgit vault is named by the SHA-256 of its ciphertext, so its name can never point at different bytes; the client checks every object against its name before using it. That is exactly the property Scion's cache tiers rest on, and the live server already uses it: an object read from the SG/Send service comes back with cache-control: public, max-age=31536000, immutable, through a CDN. Unchanged folders keep the same tree ids across commits, so they are not fetched twice.
Fetch only what you need. Scion's clients request only the trees and blobs a job needs. sgit 0.18 to 0.22 added the same family of options: --path for a scoped clone, in which "Other folders are carried by id and never downloaded", --depth for a shallow one, and --sparse for structure first and content on demand. The CLI team measured a scoped clone of one folder in 14 seconds against 81 for the full clone on a vault of 626 commits and 9,404 files; this site's agent measured the same pattern below.
Reads without the server. Scion keeps its server for reads, behind caches. sgit can do without one: because the objects are encrypted and immutable, a read is a plain GET of a known path, and 0.22.0's clone --transport static reads from "any GET host". The server only matters for writes, which go through a batch endpoint, up to 100 operations at a time, with refs moved by compare-and-swap, the same primitive Scion uses on its database row.
A server that cannot see. This is where sgit goes beyond Scion's post, which does not mention encryption. Files, file names, trees, commit messages and refs are all encrypted on the client. The server holds ciphertext, so it can be cheap, simple and anyone's: a cloud bucket, a CDN, a folder on a laptop. That is why the hosting is so simple; the server has nothing to protect and nothing to compute.
Measured on 0.22.0 {#measured}
[figure sq-bench.webp] One vault, five ways: a full clone in 58.6 seconds holding 12,664 KB of encrypted objects; depth 1 in 60.7 seconds; a scoped clone of one folder in 4.2 seconds and 412 KB; an on-demand clone in 3.6 seconds and 180 KB; and a full clone from a plain static file server in 1.6 seconds. | comparison
The agent installed sgit-ai 0.22.0, released on 15 October, and cloned a real published vault, the newsroom's synthetic-users vault of 83 files and 12 MB, with its public read key, twice in each mode. A full clone took about 59 seconds. A scoped clone of one folder took about 4 seconds and held 412 KB of encrypted objects instead of 12,664. An on-demand clone took 3.6 seconds and held 180 KB, the structure only. A shallow clone of depth 1 saved nothing on this vault, because almost all of its bytes are in the latest files; depth helps on long histories, not on young vaults.
Then the agent laid the same encrypted objects out as plain files and served them with Python's built-in file server, a program that knows nothing about sgit, and cloned from it with --transport static. The clone took 1.6 seconds on the same machine and was identical, file for file, to the clone from the API. It shows the mechanism rather than network speed, but it is the point: an sgit vault can be read from any storage that answers a GET, with no sgit server in the path.
sgit started from the same instruction Anthropic arrived at: Git solved most of the hard problems, so copy Git. Commits, trees, blobs, refs and branches, with encryption underneath, and a server that, in the words of the March brief, is "a dumb key-value blob store" while "All intelligence lives in the client." Reading Scion's post, the overlap is not in the centre of gravity, which is the opposite, but in the properties that make agents fast.
[figure sq-matrix-v2.webp] Scion, sgit and Git side by side, revised: who does the work, whether the server holds plaintext, how a folder is protected, object ids, packing, partial copies, reads without the server, writes, merge, history, implementations, deployment, proven scale and availability. | comparison
Fetch only what you need, the same way. Scion's post: "Scion's negotiation doesn't tell the server what the client already has; instead, it operates exclusively on trees and blobs the client wants. Starting from a root tree, the client checks its local store for missing trees and requests them recursively, then repeats the process for blobs." That is sgit's clone and pull walk: level by level over the trees, then the blobs in batches of 50 with 16 requests in flight. A scoped clone asks only for the spine down to its folders, and an unchanged folder keeps its tree id across commits, so it is never fetched twice.
Immutable objects, kept by whoever fetched them. Scion: "Every request is for a specific object that never changes, so any cache can answer it." Every sgit object is named by the SHA-256 of its ciphertext, and the client checks each one against its name. The name also says what it is: immutable objects carry -imm-, the two mutable pointers carry -muw-. So a browser, a proxy, a CI cache or a folder can keep an object for ever by looking at its name, without reading it. That is how sgit.ai's own documentation pages, which are a vault read in the browser, load: 18 objects cold, then one 69-byte ref, then nothing inside a two-minute window. The trade is deliberate: no deltas between versions, so a changed file is a new object.
No packfiles, no maintenance. Neither system packs objects on the server, and both treat that as a feature.
Compare-and-swap. Scion moves a ref with a compare-and-swap on one row; sgit moves the ref and the branch index the same way.
Where they differ, sharply. Scion protects directories with permissions on a server that holds plaintext. sgit protects them with keys: one vault per trust domain, a read key that cannot be turned into a write key, and append lanes that can write without reading. Files, names, trees, commit messages and refs are all encrypted on the client, so the server has nothing to protect and nothing to compute, and it can be anyone's. More on that in sgit is a standard, not a server.
Measured on a real, busy vault {#measured}
[figure sq-bench-v2.webp] The measurements now: the 83-file vault this article first measured, 59 seconds with sgit 0.22.0 and about 11 with the fix, 4 seconds for one folder, 1.6 from a plain static host; and the 35,000-object vault the newsroom's agents share, 210 seconds in full, 57 with one commit of history, 13 for one folder with one commit. | comparison
The first version measured an 83-file vault, which says little about Scion's question: what happens when the repository is big and the clients are many. The right vault was close at hand: the one the agents behind this newsroom share every day, with their mail, briefs, runs and analysis. On 16 October it had 1,295 commits, 5,281 files and about 35,000 encrypted objects, 527 MB with all its history, which is the size of a real application's source repository.
A full clone is the worst case: three and a half minutes for 35,423 objects. But no agent takes one. With one commit of history, the whole tree is 57 seconds; one 130-file folder with one commit is 13 seconds and 3 MB, 137 objects, however large the vault is. A file fetched on demand is under 3 seconds; an up-to-date pull is 2.5. The full picture, with the honest edges, is in One vault, ten agents, measured.
And the time is the distance to the storage, not sgit. The same objects on local disk: the one-folder clone takes 0.8 seconds against a local API server, the full clone 69. On the small vault, the same encrypted files served by Python's built-in file server, with no sgit server at all, cloned in 1.6 seconds, identical file for file.
1 unchanged paragraph, under Where Scion is ahead {#gaps}
TheScion memodoes Iblame, gave the agent was more optimistic than the code,bisect and the article should say where. sgit does no packing or compactionmerges on the server;server theand speed-upsbuilds inhistory 0.18indexes toas 0.22derived aredata; sgit's server cannot read a commit, so those run on the client,client. batching up to 50 objects a request with 16 requests in flight, and a vault of 35,000 objects still takes about three and a half minutes to clone in full. Merges happen on the client, three-way and whole-file; Scion does them on the server.Today sgit has apath historyhistory, logsigned onauthorship, thesigned clienttags and verification, but no blame and no bisect,bisect. whichWhere Scionit offersis throughbehind on its API,own terms: a partial clone of a long history still walks the commits one request at a time, so a folder with all 1,295 commits takes nearly four minutes, and itsa automateddepth bisectavoids andit; reverthistory pipelineslog dependfor on that. There is no command to read aone file fromover athat vaulthistory withouttakes atminutes leastof aCPU; headlessone localserver clone.process Andqueues concurrent full clones; and the largest vault sgit's team documentsit has aboutbeen proven on is 35,000 objects and 1,227ten commits;agents, Scion's hasnot 100 GB of history and 30,000 merges a day. Being designed for something is not the same as being proven at it.
Git and sgit also live side by side rather than in sync. A vault can sit in the same folder as a Git repository, since sgit ignores and a vault can be committed into .git, a Git repositoryone and attached with its key on the other side; but there is no bridge that turns Git history into sgit history or back.
1 unchanged paragraph, under What it means {#means}
I find it fascinating to watch the same idea arrive twice. Agents change what source control is for: the clients are always online, the volume is machine-scale, and the expensive thing is moving bytes nobody needs. Anthropic answered inside one trusted company, with a powerful server that does the work. sgit answers for everyone else, where the server should not be trusted at all: encrypt everything on the client, name every object by its ciphertext, let any cache or bucket serve the reads, and keep the server dumb enough that anyone can run it. The two designs meet in the middle on immutable objects, partial fetches and compare-and-swap.
The practical difference is availability. Scion is a blog post. sgit is pip install sgit-ai today, with its code in the open, and it already carries the vaults this site publishes. The useful next steps are clear from Scion's list: server-side history queries that do not need the plaintext, blame and bisect, and testing at a much larger scale. Anthropic says it wants to share its ideas with Git platforms and the open-source community. The ideas that do not depend on a trusted server are already there.
I find it fascinating to watch the same idea arrive twice. Agents change what source control is for: the clients are always online, the volume is machine-scale, and the expensive thing is moving bytes nobody needs. Anthropic answered inside one trusted company, with a powerful server that does the work. sgit answers for everyone else, where the server should not be trusted at all: encrypt everything on the client, name every object by its ciphertext, let anyone keep the objects they fetched, and keep the server dumb enough that anyone can run it. The two designs meet in the middle on immutable objects, fetching only what is needed, no packfiles and compare-and-swap.
Scion's post concedes one point from the other side: it could not keep a merge queue at its rate, so "concurrent changes can conflict, but Claude can typically fix these conflicts". The merge went back to the agent. That is where sgit keeps it: a merge is a workflow step, made where the context and the policy are.
The practical difference is availability. Scion is a blog post. sgit is pip install sgit-ai today, with its code in the open, and it already carries the vaults this site publishes and the one its agents work in. The useful next steps are on the client: a small encrypted record of the commit chain so a partial clone does not walk history, blame as a fold over path history, and testing at a much larger scale.
1 unchanged paragraph, under What this does not claim {#limits}
• sgit is not proven at Scion's scale. Its largest documented vault is about 35,000 objects.
• The measurements are small. One 12 MB vault, two runs per mode, from a cloud sandbox; the static run was local.
• sgit is not proven at Scion's scale. Its largest vault in daily use is about 35,000 objects and ten agents.
• The measurements are one run each, from cloud sandboxes. A plain connection does better.
• The fix for the small vault is not released yet. It is on the CLI's development branch.
1 unchanged paragraph
• Some features are missing. No server-side merge, blame, bisect, packing, or Git history bridge in sgit 0.22.0.
3 unchanged paragraphs, under Where this comes from {#sources}
A voice memo of mine on 16 October 2026, written by this site's agent in the voice of this site; the argument and the editorial responsibility are mine. Anthropic, Redesigning source control at Anthropic, 13 October 2026, updatedread 15 October, readagain on 16 October. Revised the same day after a review by the sgit CLI team, which measured the newsroom's shared vault from the hosted service and from local disk; this site's agent checked the cache headers, re-ran the small vault's clone with the released CLI and the development branch, and checked the quotes and the code. sgit's facts are from the sgit-ai 0.22.0package wheel, which matchesand the SGit-AI__CLI code and itschangelog; changelog,the anddocumentation pages' loading numbers are from thesgit.ai's SG/Sendlive-vault servercase code; the cache header was read from the live service. The measurements were made by this site's agent on 16 October 2026, cloning the published newsroom-synthetic-users vault with its public read key.study.