The #1 mistake with Anthropic’s Scion and Mononoke
People treat the Scion/Mononoke blow-up as a reason to ignore the design. Dismiss it as plagiarism theater. Or try to invent monorepo scaling from a blank page. Both burn time.
Copy the Bonsai + derived-data pattern in the open. Force your LLM to name prior art before it writes code. Ship a server-centric sketch that keeps writes cheap. That is what actually helps agent monorepos.
What just dropped (brief background)
Merges at Anthropic jumped from about 2,500/day in May 2026 to over 30,000/day by September. Main-branch history sat near 100 GB; compressed working copies cleared 25 GB; CI did roughly 25 million checkouts a day. A seven-person team moved the monorepo off git in five months and published the write-up on October 13, 2026.
Rain (sunshowers) – who worked on Meta’s Mononoke around 2017-18 – put the paragraphs side by side the next day. Parent-relative changesets. Recursive derived data for blame and path history. Same shape as Bonsai. Anthropic’s first version thanked Piper and Sapling for “hard-won lessons” and stopped there. After the posts and a Nick G. note on HN, a Mononoke footnote landed on October 15. Rain’s follow-up (private confirmation of personnel overlap; the name Scion as a rough syllable flip of Bonsai) is on sunshowers.io. The public fight was credit, not whether open designs may be reused.
Scion stays internal. Anthropic says it is not a general git replacement and assumes always-online clients. You want the data model, not their binary.
Method A vs Method B for agent-scale source control
Method A is the default: keep git, stand up more mirrors, lean on shallow/sparse clones, stash seeds in object storage. Anthropic ran that pattern at hundreds of mirrors and still stalled. Agents do not behave like laptops. Offline-first copies, packfile chatter, and local blame turn into the bottleneck.
| Aspect | Method A (scaled git) | Method B (Bonsai/derived-data) |
|---|---|---|
| Commit unit | Full tree pointer | Parent-relative file list + content-addressed blobs |
| Blame/history | Often O(total commits) or heavy local walk | Recursive derived data – O(commits touching the file) when done right |
| Client assumption | Works offline with a fat repo | Always online; thin cache + server RPCs |
| Write path | Local commit, push, packfile coordination | Server-side changeset; derived data off the critical path |
| Infra result (Anthropic, as of the Oct 2026 post) | Hundreds of mirrors, high CPU/memory | ~200x smaller CPU/memory footprint, checkouts in seconds, ~25% CI CPU win |
Method B fits pure agent monorepos. Thin clients. Server owns history, merges, queries. New indexes ship without client upgrades. That is the Mononoke pattern Scion reused – see the open tree under facebook/sapling …/eden/mononoke.
Detailed walkthrough: force Claude to design it the right way
Pasting the Anthropic post and saying “build this” recreates the omission. Better path:
- Prior-art lock – “List every major prior art for server-centric monorepo VCS with parent-relative changesets and recursive derived indexes for blame. Name Mononoke/Bonsai, Piper, and any others. Quote the key ideas. Do not proceed until you cite them.”
- Constraint pass – “Design a minimal changeset + derived-data layer for an always-online agent monorepo. Write path = inherent data only (changeset + blobs). Define blame and path-history as recursive derived types. Attribute every borrowed concept in the same reply.”
- Sketch and test – Ask for a Python or Rust recursive derive plus a tiny in-memory store. Feed 20 synthetic changesets with overlapping file touches. Check blame stays correct and cheap.
# Minimal recursive derived-data sketch (Python-ish)
def derive_blame(cs, parent_blames):
# cs = {id, parent_id, file_changes: {path: blob_id}}
blame = {}
parent = parent_blames.get(cs.parent_id, {})
for path, blob in cs.file_changes.items():
if path in parent:
blame[path] = parent[path] + [(cs.id, blob)]
else:
blame[path] = [(cs.id, blob)]
# unchanged paths inherit from parent (omitted for brevity)
return blame
Run the prior-art query first. Every time. Turns out both Claude Opus 5.5 and GPT-6 Astra already surface Mononoke when asked – Rain demonstrated that; the material is in the training mix. The lock is what stops the silent rename.
Pro tip: After the design lands, ask “What breaks if we eagerly materialize every derived type on every write?” Write-latency explosion. That is why both systems keep derivation off the critical path (eager or deferred, still recursive from parents).
Wire a thin client next: request only the paths you need. Sparse/virtualized checkout thinking, without pretending you have Scion’s full stack.
Ever notice how teams defend a “clean room” rewrite until the first design review? Same energy here. The model will give you a tidy architecture that never says Mononoke unless you demand the citation in the same breath as the code.
Edge cases that bite when you try this
LLMs drop attribution or rename concepts (Scion/Bonsai) even when the source sat in training data. Anthropic’s original post credited Sapling lessons and only added the Mononoke footnote on October 15 after public pushback. Require citations in the design reply itself.
The catch is implementation drift. Parent-relative changesets only make blame O(commits touching the file) if derived data stays recursive and can be deferred. Eager full-tree materialization on every write puts you back in Method A pain. Defer. Cache. Do not rebuild full manifests “just to make the UI simple.”
Personnel-overlap claims of intentional copy remain Rain’s private confirmation. Anthropic has not publicly confirmed that piece. Brief your team on the verifiable architecture match and the open Mononoke docs – treat “ripoff” as a strong allegation, not a court finding.
Under extreme write bursts, on-demand derivation can lag. Public posts do not spell out Anthropic’s exact back-pressure knobs. If your agents cross a few thousand merges/day, plan capacity for async derivation; do not assume the happy-path sketch holds.
One more thing. Is a pure rebuild still impressive? Yes – seven people productionizing this velocity is rare. Say it straight: pointing engineering (and models) at a decade-old Mononoke-shaped design and making it work for agents is a real achievement. Credit makes that clearer, not smaller.
FAQ
Is Scion open source so I can just run it?
No. Internal only, and not a suitable general git replacement. Read the design post and the open Mononoke code.
How do I actually credit Mononoke when my LLM suggests the same pattern?
One line in the design doc and the commit: “Changeset model + recursive derived data follow Mononoke’s Bonsai design (Meta Sapling, ~2018); also described in Anthropic’s Scion post.” Link the GitHub tree. Then paste the draft into Claude and ask “Does this omit required prior art?” before you publish – same lock as step 1, applied to prose.
Will this help a normal 50-dev team that isn’t drowning in agents yet?
Full rewrite? Probably not. Steal the query-API idea first: let CI ask the server for blame or merge-base without a fat checkout. Humans keep git. The Bonsai-style switch pays off when checkouts and merges dominate cost – Anthropic felt that at tens of thousands of daily agent merges, with ~25M CI checkouts/day on the old path. Watch your own CI checkout minutes and mirror CPU. When those curves look ugly, reopen Method B.
Next action: open Claude, run the three-step prior-art lock, save the sketch + citations in a repo named something honest like bonsai-derived-scratch, and send the link to whoever owns monorepo tooling.