tinyhumansai / openscion
git clone https://github.com/tinyhumansai/openscion.git
OpenScion is an open-source, server-centric source control system for very large monorepos where most clients are AI agents and CI jobs rather than people on laptops. Based on Anthropic's Scion
—
stars, 24h
+105
stars, 7 days · #480
+105
stars, 30 days · #2,191
105
★ total · +105% this week
16
forks · 13 open issues
Star history starts 2026-10-20; the chart appears after the second daily snapshot.
LanguageRust
LicenseGPL-3.0
Created2026-10-13 (7d ago)
Last push7d ago
Watchers0
OwnerOrganization
Links
- GitHub: github.com/tinyhumansai/openscion
- Homepage: https://www.anthropic.com/engineering/redesigning-source-control
- Releases · Issues · Hacker News mentions
README excerpt
# OpenScion OpenScion is an open-source, server-centric source control system for very large monorepos where most clients are AI agents and CI jobs rather than people on laptops. It follows the design Anthropic described for its internal system, Scion, in *Redesigning source control*. ## Benchmarks `opnscn` against git on synthetic repositories of 4 KiB files, measured with `openscion-bench` (`cargo run -p openscion-benchmarks --release`): OpenScion imports and clones several times faster than git at both sizes. The one-directory clone shows the design at work: `opnscn` fetches only the trees on the path to the directory and the files beneath it, so its cost tracks the slice you ask for rather than the size of the repository. Setup, methodology, and raw numbers are in `benchmarks/README.md`. ## Why Git assumes every client is offline and keeps a full copy of history. An agent-heavy monorepo breaks that assumption. Thousands of short-lived, always-online jobs each want a small slice of a huge tree, and each one pays for the whole repository anyway. Anthropic reports going from about 2,500 to over 30,000 merged changes a day in four months. At that point the main-branch history was almost 100 GB, CI ran about 25 million checkouts a day, and they needed several hundred git mirrors to keep up. OpenScion takes the opposite approach: - **The server does the work.** History, blame, commits, rebases, and merges run server-side. A client keeps a bounded cache and lays out files. - **Changesets, not snapshots.** A changeset lists only the files that changed relative to its first parent. Creating one costs the size of the change, not the size of the repository. - **Content addressing everywhere.** Blobs, trees, and changesets are named by their BLAKE3 hash. Any cache at any tier can serve them without coordination, and any client can verify them. - **Few refs, moved by compare-and-swap.** Creating a changeset never touches a ref. Landing is a server-side rebase plus a single-record swap, retried on contention, with no global merge lock. - **Source control as an API.** Log, diff, blame, ancestry, rebase, revert, and land are RPCs, so CI and bisect pipelines need no checkout. - **Fetch only what you name.** Clients request specific trees and blobs instead of negotiating packfiles, so sparse checkouts need no special support. OpenScion is purpose-built for one workload: large monorepos where most of the traffic comes from agents and CI jobs. Server-side operations, fetching only what is named, and lock-free landing are what keep thousands of concurrent clients fast at that scale. ## Architecture [code] All tiers answer the same object RPCs, so a client talks to whichever one is nearest. Mutable state (the log, refs, and derived indexes) lives only on the server. Storage sits behind two ports, `ObjectStore` and `MetadataStore`. The reference implementations are in-memory and local (filesystem, SQLite), so a single node works without any cloud service