📈 GH Trending Explorer 🎲 Surprise me

← all repos

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

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