Browser can be local. What’s nice about browser based is that browser based programs can run on every device. Though it sounds like this one requires chrome which seems weird to me.
(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.
We maintain a semi-large complexity application with plugin support in Qt. I was able to port it to webassembly in under a day a few years ago, it was essentially a process of hunting build issues in dependencies, patching QOpenGlWidget’s behaviour and adding a few #ifdefs around platform specific code. A bit of fun, seems like a good use for an LLM but not overly complex to achieve.
Onshape is free in the browser as long as you are not doing commercial work. It’s a professional system from the founders of Solidworks that competes with all the top CAD tools.
> It’s a professional system from the founders of Solidworks that competes with all the top CAD tools.
Because it's built on Parasolid, the same geometric kernel as everyone else. With ACIS pretty much out the door, almost all the professional CAD packages are just window dressing on the same CG implementation.
Agreed. I’m not OP but for six months I’ve been using Claude to build a from-scratch CAD kernel based on Rust and WASM, MIT licensed.
The actual UI still needs a lot of work, but I’ve been focused on the kernel. Fable has helped a lot though Opus was already making great headway.
I’m an OnShape power user going back about ten years, Solidworks before that. I need a CAD system that absolutely works. There is a lot of work to do still, and it still seems impossible to succeed, but I’ve been very happy with where things have been going with it lately.
It’s serverless, local, and browser based. You can load the latest binary from GitHub pages here:
The app consists of a wasm (web assembly) binary and JavaScript. The wasm runs locally on your machine in your browser and communicates with the JavaScript frontend. There is no backend server to handle any part of the program. The URL just loads the binary in to your local browser. I don’t know exactly how one would set this up but this would work for example fully offline. The browser basically just becomes a universal compute and rendering engine for it.
Heh, me too. I'm on my third rewrite after a bunch of promising false starts.
Unfortunately geometric kernels are one of those things where unknown unknowns will bite you in the ass really hard because none of the content is really in the training data for LLMs and pathological/degenerate cases aren't just common but expected. IME it's not something that can be vibe coded with current models, if ever, without intimately understanding the algorithms.
I can't do a thorough review of waffle iron right now but just off the top of my head: it doesn't look like you have a tolerance context? The tolerances look like hard coded constants (TAU_MODEL/TAU_WORK/MATCH_TOLERANCE/etc) but that's fundamentally unworkable. Each operation and vertex/edge/etc needs to track accumulating errors and apply them to downstream point classification. Interfaces like Kernel::boolean_union(a, b) are the wrong abstraction because it's missing tons of information/functionality like accumulating FP errors, evidence/proofs, rollback, etc.
Thanks! I had a lot of false starts too. I asked fable in my repo about your question and it said there are two schools of thought on tolerance tracking. My kernel uses exact predicates which fable says eliminates the need to track tolerances the way ACIS does. I tried to paste the full reply but my comment seemed to have been auto flagged.
I think Fable gave you a load of nonsense. Like I said, this stuff isn’t really in the training data and academic research is disconnected from commercial CG (and I’m pretty sure its wrong about ACIS - iiuc ACIS did what you did and its one of the reasons it lost to PS).
Robust/exact predicates (certifying topology) and tolerance tracking (accumulating floating point errors) solve two different things and a geometric kernel needs both, especially if you plan on letting models use meshes, lattice, or freeform surfaces. The constructions you feed the exact predicates need to already account for tolerances to be correct (i.e. pcurves, trims, etc)
Basically. Moreover though it’s cloud based so you can’t run it with a poor connection or no connection. They could change their mind at any time about free accounts and lock users out. Free accounts can’t make private files. And I don’t know if OnShape is accessible to everyone in every country.
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.
The launch graphic says "Ported end-to-end by Fable, an AI agent" and it definitely feels that way. Buggy, glitchy, needs some love and human eyes before it's really usable.
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
24 comments
[ 5.1 ms ] story [ 39.5 ms ] threadI 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.
Because it's built on Parasolid, the same geometric kernel as everyone else. With ACIS pretty much out the door, almost all the professional CAD packages are just window dressing on the same CG implementation.
The actual UI still needs a lot of work, but I’ve been focused on the kernel. Fable has helped a lot though Opus was already making great headway.
I’m an OnShape power user going back about ten years, Solidworks before that. I need a CAD system that absolutely works. There is a lot of work to do still, and it still seems impossible to succeed, but I’ve been very happy with where things have been going with it lately.
It’s serverless, local, and browser based. You can load the latest binary from GitHub pages here:
https://sequoia-hope.github.io/waffle-iron/
Click the Assay menu to see the kernel test cases we’ve been using so far. Rapidly closing on 100% support!
uhh what..
Unfortunately geometric kernels are one of those things where unknown unknowns will bite you in the ass really hard because none of the content is really in the training data for LLMs and pathological/degenerate cases aren't just common but expected. IME it's not something that can be vibe coded with current models, if ever, without intimately understanding the algorithms.
I can't do a thorough review of waffle iron right now but just off the top of my head: it doesn't look like you have a tolerance context? The tolerances look like hard coded constants (TAU_MODEL/TAU_WORK/MATCH_TOLERANCE/etc) but that's fundamentally unworkable. Each operation and vertex/edge/etc needs to track accumulating errors and apply them to downstream point classification. Interfaces like Kernel::boolean_union(a, b) are the wrong abstraction because it's missing tons of information/functionality like accumulating FP errors, evidence/proofs, rollback, etc.
Keep working at it! It's worth the challenge.
Robust/exact predicates (certifying topology) and tolerance tracking (accumulating floating point errors) solve two different things and a geometric kernel needs both, especially if you plan on letting models use meshes, lattice, or freeform surfaces. The constructions you feed the exact predicates need to already account for tolerances to be correct (i.e. pcurves, trims, etc)
Edit: to be precise 'maxed out' means one weekly limit on fable used over those 4 days
LibreCAD in the Browser - https://news.ycombinator.com/item?id=48755075 - July 2026 (17 comments)