(I made this port) Fwiw I personally had no reason to do this port beyond using it as a benchmark of the agentic capability of Fable, where something of this shape is IMO a way better gauge than those dumb X.com 'I oneshot game with models X/Y/Z this is how it compares'
I published the actual prompts, and you can see quite clearly that vs Opus which is ok at implementing one big feature, Fable was really able to push through a good chunk of the port. That said it definitely didn't one-shot the port, it also didn't figure out a broken docker sbx sandbox by itself, and also later needed some gaslighting into thinking that the port is not really that hard (by any human measure it was quite hard given the scope of code involved.. The nearly 200MB wasm binary is mostly code afaict..). So there are some clear patterns of how the model was trained and also roughly the scope of task visible in those traces. What I see is that it likes prompts that would take an L4/L5 2-4 weeks to do with Cursor ~2 years ago, more needs some direction and deliberate prompting.
I will also note that it's possible to compile this with wasm asyncify, but the result iirc is a ~400MiB Wasm binary that will crash the browser tab before you will be able to do anything useful in it.
I made the port, roughly ~one maxed out Claude Max 20x sub, at the bottom of the article I've shared the full claude code transcripts, so you can probably to some rough math on token usage with that.
Edit: to be precise 'maxed out' means one weekly limit on fable used over those 4 days
Author of the port here, you need a browser with JSPI support, which means recent Chrome, or Firefox Nightly with the feature flag flipped, or Firefox from the future.
Just enabled, however note that I don't really intend to support this much more, but would happily get this repo to someone who would want to support wasm mode more properly / ideally upstream in longer term
If you believe a 128gb machine that is essentially DGX Spark in a laptop chassis can run models comparable to SOTA you either never ran open models on hard tasks, or you aren't scratching the surface of SOTA closed LLM capability in how you're using them.
For the stuff in more sensitive deployments it's really quite simple, just setup CORS etc properly and don't do anything overly fancy on the frontend. Worst case the user may force some internal function to eval some JS by pasting scripts into the browsers debug console.
Critical severity vulnerabilities are only critical when they are reachable, but are completely meaningless if your application doesn't touch that code at all. It's objectively more risky to "patch" those by updating dependencies than just let them be there.
If it runs in a harness that will alert me when something dodgy is detected I'm fine to stay at that level.
I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea.
Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that often, really when something either breaks or there is a legitimate security reason to do so, which in deep systems software is quite infrequent.
Funnily enough for frontend NPM code our policy was to never ever upgrade and run with locked dependencies, running few years old JS deps. For internal dashboards it was perfectly fine, never missed a feature and never had a supply chain close call.
Cargo is spiritually based on NPM so it's not much better.
Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view.
Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.
In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.
Funny you mention that, I have very recently just came back from a one-shot prompt which fixed a rather complex template instantiation issue in a relatively big very convoluted low-level codebase (lots of asm, SPDK / userspace nvme, unholy shuffling of data between numa domains into shared l3/l2 caches). That codebase maybe isn't in millions of lines of code but definitely is complex enough to need a month of onboarding time. Or you know, just give Claude Opus 4.5 a lldb backtrace with 70% symbols missing due to unholy linker gymnastics and get a working fix in 10 mins.
And those are the worst models we will have used from now on.
I published the actual prompts, and you can see quite clearly that vs Opus which is ok at implementing one big feature, Fable was really able to push through a good chunk of the port. That said it definitely didn't one-shot the port, it also didn't figure out a broken docker sbx sandbox by itself, and also later needed some gaslighting into thinking that the port is not really that hard (by any human measure it was quite hard given the scope of code involved.. The nearly 200MB wasm binary is mostly code afaict..). So there are some clear patterns of how the model was trained and also roughly the scope of task visible in those traces. What I see is that it likes prompts that would take an L4/L5 2-4 weeks to do with Cursor ~2 years ago, more needs some direction and deliberate prompting.