Anthropic's Scion is heavily inspired by Mononoke
sunshowers.io
sunshowers.io
“Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind.”
Mononoke is a component of Sapling, as I understand it. In fact, the repo link provided in this article links to a subdirectory of the Sapling repo. I’m not totally sure I understand the complaint.
To be uncharitable, this is marketing for Anthropic's impending IPO.
Even if they weren't making a lot of PRs, Github has been melting down enough this year that they've probably encouraged customers like Anthropic to move off.
Git is just not suited to truly large monorepos, and it won't ever be. That's totally fine, of course. Less of a monoculture here would be great.
> under 1 commit per second
Sure, for arbitrary pushes, that's not a big deal. But for large repositories, with those changes landing on trunk at that rate, once you start talking about "commits per second" it gets very difficult.
Just for comparison' sake: Google employs ~60,000 engineers. Anthropic has maybe 2,000. My uncharitable (and admittedly unverifiable) read is that even if they weren't directly experiencing this problem, the optics of being their size but needing Google or Meta-level scale for their work is a comparison they are happy to invite folks to make going into IPO season.
Maybe they do! But, well, I simply do not find them a reliable narrator.
Mononoke and Sapling are open source systems. Why shouldn't new software take inspiration from how they are designed?
> And, to be clear, I do not have a problem with Anthropic copying Mononoke’s design. (This is part of why we put out open source — to benefit humanity through the spread of good ideas.)
> But as LLMs continue to assist in designing new systems, they are likely to index heavily on existing designs. Mononoke is open source and in every LLM’s training set. If you ask Opus 5.5 or GPT-6 Astra (thanks Matthew Fowle) about prior art, they both immediately point out the similarities to Mononoke.
> Giving credit to those that came before us is now easier — and more important — than ever. There is no longer an excuse.
Fair enough.
I thought it was likely that their team of 7 included ex-Meta and ex-Google people with knowledge of those company's internal version control solutions.
If we s/Claude/Few Meta engineers/, would de novo still hold?
There are things in this world that people can and should be stopped from doing, and there which anyone can do unhindered if they so wish. In between those two boundaries there’s a standard of decent behavior that one should strive for in order to be considered a good person.
Giving credit isn’t required, but many consider it basic decency.
That’s not surprising to me - they designed and built it using their LLMs, of course it’s duplicating prior work. That’s essentially the core of what LLMs do, after all.
The intended audience is obvious from first paragraph alone:
> At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.
Translation:
> We are so far at the cutting edge we need to build shiny new infrastructure to replace the smelly "human scale" cruft. How could you /not/ value us at $2T?
Claude.ai
Claude Code CLI
Claude Code Desktop (multiple platforms)
Claude Code on the web (aka Claude Code Cloud)
Claude Design
The Claude API
Claude SDK libraries
Cowork (just retired and merged into regular Claude)
Claude Tag
Claude for Legal
They ship a lot of products.
Even that one repo is breaking GitHub this week…
Another Claude-written article
This is the load-bearing seam.
However if my new car's engine is a near copy of the one in the Corvette, and my announcement gushes about the engine using the same terms the Corvette design team invented...
Then can you see how a mention might be nice?
If you take the statement: "Pretty much 100% of our code is written by Claude Code" (https://x.com/bcherny/status/2015979257038831967)
And you take the statement: "Mononoke is open source and in every LLM’s training set."
There is not much resemblance with any cleanroom implementation anymore.
Interesting explainer in this intro for those who don't know the principle:
https://www.ntari.org/post/how-clean-room-reverse-engineerin...
Perhaps if there is any ambiguity, it's intentional on the part of caution around intellectual property provenance.
And then I noticed some links to images from random small github projects and realized somewhere along the way agents had searched for existing projects and copied almost everything.
I wonder if something similar happened here on a larger scale.
More seriously, I'm curious if you checked on the licensing of said codebases, were they permissive or strong copyleft?
While that's not technically the case here (given Mononoke's license) it is still quite negative in my view. We will have fewer people wanting to share ideas openly since LLMs are so good at not only finding them, but also not attributing them. This also leads to a loss in diverse collaboration, which is probably one of the biggest drivers for good software.
Right now there's probably a lot of these "novel" ideas floating around which models can present as their own, but that's raiding our coffers with no inbound future stream.
There are two cases and only one is an issue for citations: - Mononoke was directly consulted and not attributed - Concepts were reinvented or used as a derivative (Sapling cited Mononoke and implements something similar)
For one I know Sapling, Git, and Jujutsu, but up to today I have never heard of Oxide or Mononoke and I am not exactly compelled to look up the research papers of any of them, at most I read through their high level documentation.
Projects seem to be getting approved or pushed there purely on the basis of showing off that they can vibe-build infrastructure.
Which.. yes, you can. But now maintain it. Understand it. Manage thousands of people using it. Those are part of the reasons we re-use proven solutions rather than rolling our own -- not just because the coding part is hard.
Same thing happened with the Bun rewrite. "Oh wow, look what we can do! What's that, nobody adult supervision telling us that this is a bad idea? Let's go!"
On one hand they say AI will end the world. On other hand they say well, we just merge PR by reading the "intent" which I think is the AI summary
I cannot hate them - its rational in its ways. But I hate the idiots who fall for it with each new IPO.
I guess that is the case.
If only they had had a claude write the post, it'd be full of citations, inspiration credit etc.
Centralized, virtual file system, all commits automatically on cloud, large binary files totally fine, Mercurial CLI. It’s fantastic. People who only use Git really don’t understand how much better things can be.
(Like GH finally has some support for stacks, 15 years late, with an implementation which is somehow more complicated and less powerful than the prior art...)
I agree so hard. It’s inertia is too strong and we’ve stalled progress for a decade.
Most people aren't VCS nerds, most are of a generation that only ever knew git. Learning git was a prerequisite they engaged with out of necessity, not by choice, not after exploring the problem space and pondering about different approaches. Learning git was difficult, and the more they learned the more they discovered they had more to learn, including the little things, obscure details and a plethora of paper-cuts. For them (again, I suspect they are a majority), the perspective of learning something else comes with the expectation of a similar daunting effort and steep cognitive reluctance.
That's the paradox of git as I see it: had it been a simple and easy system to pick-up, it would probably have been replaced, and/or the VCS space would be much more competitive.
You just blew my mind with this. This is shockingly profound.
(Okay not literally exactly, for example, jj/git not hg. But the vibe is the same.)
There's not really a VCS meetup in NYC, but I got to hear David and others at Rust NYC wax eloquent about Sapling vs Piper and Buck vs Bazel a couple of times, so I think the audience is there!
Maybe, we'll see. I think one thing that's tricky these days with startups is that being super transparent technically about what you're up to is much harder to justify. Look what happened with Origin: tobi vibed up a copy over the weekend after it was announced. Obviously there's balance to be found here, but that's partially why we play our cards a little closer to our chest.
Let me share with you my previous screeds on this topic:
* https://www.forrestthewoods.com/blog/dependencies-belong-in-... * https://www.forrestthewoods.com/blog/using-zig-to-commit-too...
They’re semi-adjacent in that they are about build systems that don’t suck. (buck2 is also mostly TheWay but also not usable outside of Meta and has room for improvement).
Save us from Git and CMake Steve! Please I beg you!!
I do care about Windows, having used it for years at this point. The client is git or jj, so Windows support is there for sure. For some of the other stuff we’re doing, we’ll see what customer demand is like. Obviously there are tons of devs on Windows, but we also have to make calls about priorities too.
Whether it is plagiarism or hacking, the buck has to stop with the operators. It's not a good look.
IP maximalism is the present zeitgeist but that’s just how knowledge flows.
Open source is not IP maximalist by any means. I am merely asking that the appropriate credit be provided.
Written about it here before: https://wiki.roshangeorge.dev/w/Blog/2026-09-08/Intellectual...
It isn’t something I care very much about, except when it’s used as a certificate of achievement. I almost never do literature searches with an attempt to dedupe. I only ever do it to see if someone has explored something better than I have. That’s often the case but other times it is not.
The first step in approaching anything difficult is seeing whether someone else has already solved it.
I agree that there will be cases where you implement tricks that others have had before you, without knowing. A few years ago, I had a delightful idea, experimented and wrote it up. One commenter directed me to a post that described it as "folk knowledge". There will be other cases where you encountered an idea before, but didn't remember it.
Still, crediting what you can easily know you cited is good. Even aside from credit, comparisons to existing systems are part of how we understand what a system does.
- https://www.anthropic.com/engineering/a-postmortem-of-three-...
- https://www.anthropic.com/engineering/how-we-contain-claude
That's how the knowledge that it was a facsimile was lost.
What is douchey is presenting the whole thing as some sort of intense novelty and stroke of genius required in the age of agents when it's just doing what the other BigCo companies did to scale their monorepos already. Like a decade (or more) ago.
The reality it is when I first read the thing I was -- as a Xoogler -- like "Oh, yeah, so, like Piper & SrcFs and the stuff that Meta also does" and really didn't understand why they wouldn't have started with something off the shelf inside of vibe-conjuring a clone that they would then have to support
To me it speaks ill, again, of the engineering culture at Anthropic. "We do these things not because they are useful, but because they are novel."
Don't they have better things to do at Anthropic than building their own source control or rewriting Bun from scratch in another language? Like, y'know, basic site reliability? Or a coding harness that doesn't eat multiple GB of RAM?
Google's isn't open source. Meta's is an option, any others you would consider?
Even Google started with Perforce originally and only forked/rebuilt when it stopped being able to scale. And did so in a very incremental fashion.
You can write it, but can you maintain it? Can you even fully understand what was built? Can you staff the team to manage the bugs? The potential data loss?
If you're using Anthropic's recently-announced plagiarized source control system as your proof that this is possible, then, well, it's still not possible. That system was not built from scratch, and we both know that you were informed roughly four hours before posting this comment that the folks involved with this have been directly informed of that fact. You even called the failure of Anthropic to acknowledge that this was not a from-scratch project and to credit the project from which they lifted the design that they would have had to pour a lot of time and effort into to replicate -and I quote- "a scandal".
We've since got a few more details, it looks like the new information is that there are people on the team who built Scion who had previously worked at Meta and had direct experience with Sapling and Mononoke: https://sunshowers.io/posts/anthropic-mononoke-2/
I stand by my original comment: back when Google built their version of this it wasn't possible for a team of seven to use LLMs to build a new custom implementation in five months that incorporated existing patterns (in a way that some people would classify as cheating / plagiarism / insert-your-criticism-here).
A quick look around tells us that Mononoke came from Facebook nine years ago. [0][1] Similarly, Piper was built long before LLMs were more than -at best- some very small scale implementations.
Git was started in 2005. IIRC, it went from a blank editor window and some ideas in Torvalds's head to self-hosting in four days and managing the code for the then-latest Linux kernel release in two months. As I understand it, project staffing was also low; somewhere between one and a handful of people. Such amazing velocity and tiny staff size! <strike>Impossible without LLMs!</strike>
I also note that you've weakened your claim from "build a new system from scratch" to "build a new custom implementation ... that incorporated existing patterns". [3]
> Here's the context for that "scandal" comment...
Yes, that's the conversation that I wrote about. The rather unflattering start to that thread that you linked is important context [2], and the blog post you link to talks about the behavior you called "a scandal". I read all of the discussion for the first report, and most of it for the second.
> I stand by my ["]original["] comment...
Like many folks have mentioned to in recent months, occasionally saying "Jeez, that behavior is awful. Yeah, that's inexcusable." doesn't mean anything when you're back at bat for these companies a few hours later.
[0] <https://github.com/facebookarchive/mononoke>
[1] <https://news.ycombinator.com/item?id=16565299>
[2] <https://lobste.rs/c/wk6js5>
[3] The following paragraph from 'anthropic-mononoke-2' seems particularly apropos in light of how you've shifted your claim since I objected to it:
*This makes Anthropic’s achievement significantly less impressive.* Anyone who’s put a distributed system into production knows how many issues tend to crop up during the productionizing process. “Our LLM built this thing, productionized it, and dealt with all the attendant challenges over 5 months” is a significantly more compelling narrative than “the source control team at Meta had spent 10 years building and productionizing this system, and we were able to point our LLM at it and rebuild it in 5 months”.Others read it and interpreted it as "a team of seven engineers designed this software and used a Claude to build it".
The former group seem a whole lot more outraged by this situation than the latter. Which interpretation did you take from Anthropic's post?
Neither. Anthropic originally claimed the same thing that you originally did in this thread; that this was a from-scratch implementation, and that the use of LLM-based tools was the primary reason they could go from zero to a nontrivial version control system in ~five months.
Please stop going to bat for these folks.
The issue, fundamentally with Anthropics announcement is apparently "attribution, not copying."
The Mononoke project sits in a facebook org repo, so i assume it's a Meta project.
So I guess my question is, if it's good for one company, why isn't it good for the other company?
I realize real people work at these companies, but I can't feel sympathy.
The amount of training data for incremental/derived data systems is quite sparse in the grand scheme of things. I've seen little to no improvement over the last year when testing new models in that area, they always make some pretty bad mistakes, and what is correct is very inefficient.
Edit: I was too lazy. From the README: "Mononoke is the server built for the Sapling Source Control System"
1. Sapling can refer to either the system as a whole, or just the client people use (`sl`, forked from `hg`).
2. EdenFS is the virtualized FUSE filesystem (closely modeled after SrcFS at Google).
3. Mononoke is the distributed system that implements the backend server storage + the API they describe for checkout-less writes.
All three come together to form the core of the Meta source control experience. From what I can tell, Anthropic built its own version of 1 and copied 2 and 3, plus also built out a code review tool separately.
They’ve been the most egregious offenders as of late
Another effort I couldn't have done without Astra. Even more so. All I did, the only reason I got cited, was because I'd asked Astra.
[1] https://en.wikipedia.org/wiki/Open-source_software_movement
> And, to be clear, I do not have a problem with Anthropic copying Mononoke’s design. (This is part of why we put out open source — to benefit humanity through the spread of good ideas.)
Followed by:
> But as LLMs continue to assist in designing new systems, they are likely to index heavily on existing designs. Mononoke is open source and in every LLM’s training set. If you ask Opus 5.5 or GPT-6 Astra (thanks Matthew Fowle) about prior art, they both immediately point out the similarities to Mononoke.
I think it is the duty of any responsible engineer to look for and cite prior art and related work, if only to compare notes.
Maybe 5 years ago that would be the expectation but all etiquette has been thrown out the window with AI. I think you expect too much.
Open source licensing protects direct copying. It does NOT protect re-implementing from scratch. See all the lawsuits around Java. You should not be using open source software if you don't want others to read your source!
The patent system actively discourages this by tripling damages for knowing violation, as does the copyright system by the threat of accusations of copying that are best defended against by 'I never saw it'. It's much safer, legally speaking, to explicitly avoid doing this.
What would you classify the rust rewrite of Bun as? Because that's what we're looking at here.
Uhuh:
> To solve this, we moved the diff-friendly representation to being derived data (i.e. an index).
Coming up with the idea of an index is not a novel thought. Nothing Anthropic described in their post was anything unexpected that one working from first principles that their problem presented would not have come up with.
As I suspected at the time of writing the post (but could not verify) and as was later confirmed in private correspondence to me, Anthropic did not come up with this from first principles. Claude was pointed directly at Mononoke and asked to re-engineer it.