# Scion and sgit: what changed in v1.2.0, sgit.ai > The changes to the article "Scion and sgit" in v1.2.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Scion and sgit](../../scion-and-sgit.md) / [Versions](../scion-and-sgit.md) / v1.2.0 # Scion and sgit: what changed in v1.2.0 From v1.1.0 (2026-10-16, `ae3c7e836`) to v1.2.0 (2026-10-16, `62d7d61bb`), paragraph by paragraph. 1 paragraph added, 7 removed, 5 changed in place, 38 unchanged. About 101 words added and 368 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [← v1.1.0](v1.1.0.md) · [all versions](../scion-and-sgit.md) 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: immutable objects named by the hash of their ciphertext, which anyone can keep for ever; a server 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 headline measurement turned out to be a bug: the 59-second clone was a size limit and a slow fallback, now fixed, and the same clone takes about 11 seconds. After the sgit CLI team reviewed it, the article now carries the measurement that answers Scion's real question,Measured on the 35,000-object vault the agents behind this newsroom share every day:day, 35,000 encrypted objects and 1,295 commits, an agent takes one folder with one commit of history in 13 seconds and 3 MB.MB, however large the vault is. The differences are real too. Scion does history, blame and merges on the server and runs at a scale sgit has never been tested at; sgit does them on the client and has no blame or bisect 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. 8 unchanged paragraphs, under In short {#in-short} • **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. 6 unchanged paragraphs, under What Anthropic built {#scion}, Why I recognised it {#recognised} !shot sq-matrix-v2.webp | images/ | Scion, sgit and Git side by side, revised:side: 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 1 unchanged paragraph **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 server also sends a one-year `immutable` cache header, though the CDN in front of the hosted API does not yet serve object reads from its cache; browsers, clients and static hosts do. The trade is deliberate: no deltas between versions, so a changed file is a new object. 5 unchanged paragraphs, under Measured on a real, busy vault {#measured} The first version measured anAn 83-file vault, whichvault 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 oneis 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. 1 unchanged paragraph On a small vault the client's own edges show instead: an 83-file vault took 59 seconds to clone with sgit 0.22.0, because two batches of objects were over the size limit of the Lambda that serves the API and the client fell back to reading one object at a time; the CLI's development branch splits a refused batch in two, and the same clone takes about 11 seconds. 16 unchanged paragraphs, under Where Scion is ahead {#gaps}, What it means {#means}, What this does not claim {#limits}… 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](https://www.anthropic.com/engineering/redesigning-source-control), 13 October 2026, read again on 16 October. RevisedThethemeasurementssame day after a review by the sgit CLI team, which measuredof the newsroom's shared vault are the sgit CLI team's, from 14 and 16 October, 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](https://pypi.org/project/sgit-ai/) package and the [SGit-AI__CLI](https://github.com/SGit-AI/SGit-AI__CLI) code and changelog; the documentation pages' loading numbers are from sgit.ai's live-vault case study. [← v1.1.0](v1.1.0.md) · [all versions](../scion-and-sgit.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/scion-and-sgit/v1.2.0.html)*