QWE AI Academy End result: sparse agent checkouts, worktree isolation, post-merge safety nets. Your coding agents stop choking git the way Anthropic’s fleet did before Scion.
On Oct 13, 2026 Anthropic published how merges went from ~2,500/day (May 2026) to over 30,000/day (September 2026). A seven-person team moved the monorepo off git in five months onto an internal system named Scion. You cannot install it. You can copy the workflow moves that still work on plain git this week.
Key takeaway (read this first)
Git assumes offline humans and fat local trees. Anthropic’s load is mostly always-online agents and CI. Scion puts history, blame, commits, merges, and rebases on the server; clients keep a bounded cache and pull only what they touch. The official engineering post reports ~200× smaller CPU/memory versus hundreds of git mirrors, CI checkouts in seconds instead of minutes, and about 25% CI CPU freed.
Don’t rebuild Scion. Stop shipping the whole monorepo to every agent run. Stop treating merge queues like a human-paced lock.
Method A vs Method B
| Method A: Patch git harder | Method B: Scion-inspired workflow | |
|---|---|---|
| Core idea | More mirrors, seeds, shallow clones, bigger runners | Clients stay online; fetch less; push ops server-side when you can |
| Checkout | Full or shallow full tree still common in CI | Blobless + cone sparse per job/agent; skip disk when an API/diff is enough |
| Branches | Branch per agent forever | Short-lived worktrees/sessions; few long-lived refs (main/release) |
| Safety | Serialize on a merge queue | Post-merge + pre-deploy tests; concurrent land; auto-fix conflicts |
| When it wins | Smaller repos, mostly human commits | Agent fleets, fat monorepos, CI fan-out |
Method A is what they already maxed out – shallow clones, sparse checkouts, seeds, several hundred internal mirrors – until merge rate made the workarounds hurt. Method B wins when agents outrun human-scale plumbing.
Think of a hundred interns who each clone the company drive “just in case,” then grep history for answers an API already knows. That’s the failure mode. The fix isn’t a sterner lecture about git hygiene. It’s shrinking what each intern is allowed to materialize.
Background worth one screen
Main-branch history alone: almost 100 GB. Compressed working copy: over 25 GB. On the order of 25 million CI checkouts a day – naive full fetches would top 600 PB. They named prior art in the open: Google’s Piper and Meta’s Sapling (sparse profiles, scale around files in use; internal virtual FS / server pieces).
Same five-month window: Antique (code review), code search, richer IAM. Claude drove the volume and a chunk of the repair – an early Mythos Preview rewrite of git→Scion ingestion used 20× less memory and ran 4× faster, per that post.
Walkthrough: Scion-style habits on plain git
1. Every agent/CI checkout pays only for paths it touches
Partial clone + cone sparse-checkout is the git-native version of sparse/virtual working copies:
git clone --filter=blob:none --sparse https://github.com/ORG/MONOREPO.git
cd MONOREPO
git sparse-checkout init --cone
git sparse-checkout set services/billing packages/sharedIn GitHub Actions, drive the same pattern through actions/checkout with sparse-checkout and keep the clone blobless. Community monorepo guides (for example shallow/sparse CI checkout notes) push this for the obvious reason: a billing-service job should not materialize forty unrelated packages.
Pro tip: CI preflight that fails if build/test scripts touch a path outside the sparse cone. Kills the “works on a full laptop clone, dies on the agent runner” flake class in one check.
2. Worktrees for agents – not permanent branch forests
Scion discourages global refs outside main/release: shared pointers everyone must agree on are a scaling tax. Mirror that spirit:
git worktree add ../agent-billing-$$ -b agent/billing-$(date +%s)
# point Claude Code / your agent cwd at that worktree
# when done: merge or open PR, then git worktree remove ...One worktree per session. Shared object store, isolated dirty trees. No abandoned long-lived branches for every server to track.
3. Server-side answers beat local full history
Many jobs never need a working copy – only an answer.
- Forge APIs / GraphQL for PR metadata, merge time, file lists.
- Host compare endpoints for merge-base diffs when the job won’t compile anything.
- Warm partial mirror per region for hot paths only – not hundreds of full monorepo mirrors.
Turns out some internal tools linearly read the commit log to learn when a change hit main instead of asking the review system. Ban that in agent prompts and CI scripts before it reappears as “helpful” agent behavior.
4. Safety later: post-merge and pre-deploy
Hundreds or thousands of changes can land while one suite is still running. A classic merge-queue lock stops matching that clock. Anthropic leaned on post-merge and pre-deploy automation instead; concurrent conflicts still show up, and they report Claude often fixes them before humans notice.
Do this in your repo:
- Path-filtered CI on the PR (fast, sparse).
- Land to main without a multi-hour serial queue when risk is contained.
- Continuous main-branch suite + deploy gate that rolls back or auto-opens fix PRs.
- Review intent (what/why), not every generated line.
False serialization feels like control until merge rate leaves human pacing behind. Measured recovery is the control that still works.
Edge cases that bite when you copy the idea
Full-tree assumptions. Language servers, monorepo task runners, “find every package.json” scripts blow up when dirs aren’t on disk. Document a sparse profile per product (Sapling-style sparse profiles are the same sparse-profile pattern) and pull transitive deps into the cone.
Blob-on-demand storms. Partial clones move cost to first access. Warm common blobs in a shared node cache – Anthropic’s daemon/cache path is described with >99% hits per tier for a reason – or cold runners thrash origin.
Agent history abuse. Agent “debugging” via deep clone + grep recreates the 600 PB fantasy in miniature. Constrain tools: no full unshallow unless a human flags a history bug.
Offline humans still exist. Scion is aimed at enormous monorepos and always-online agents, not a laptop on a plane. Keep classic full clones for people who need them; optimize the agent/CI path first.
FAQ
Can I download Scion and switch my company off git?
No. Not a general git replacement, not public, needs bespoke review/search/CI. They’re sharing design pressure and want forge/OSS partners – not shipping you a tarball.
We’re at a few hundred agent PRs a day, not 30k. Worth it?
Selectively, yes. Sparse CI for monorepo jobs + worktree-per-agent isolation cut clone time and merge mess long before you need server-side changesets. They expect this pressure class to show up more in the next 6-12 months as coding agents spread; grab the cheap wins first.
How is this different from just using Sapling or jj?
Sapling already pushes sparse working copies and kinder stacked workflows; Meta’s deeper server/virtual FS pieces aren’t a drop-in external Scion. jj can smooth local agent UX. Neither alone redesigns checkout policy, branch lifetime, and CI timing for fleets of always-online agents. The architectural read: server as source of truth, working copy optional – not “swap the CLI and hope.”
Next action: pick one monorepo CI job that still full-clones. Convert it to --filter=blob:none + cone sparse-checkout for the paths it actually builds. Add the preflight path check. Measure wall time and cache hit rate on the next 20 runs. Then default every coding agent onto its own worktree.