FreeCAD in the Browser
magik.net
magik.net
LibreCAD in the Browser - https://news.ycombinator.com/item?id=48755075 - July 2026 (17 comments)
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.
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..
I set up remote tmux access to my phone right at the beginning so I have been advancing it rather continuously during my waking hours. Especially the last few months which have been a very focused push on a new kernel architecture.
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/(adaptive) exact predicates and tolerance tracking solve two different things and a geometric kernel needs both, especially if you plan on letting models use meshes, lattice, or freeform surfaces (which is where the industry is headed for simulation driven design). The constructions you feed the exact predicates need to already account for tolerances to be correct (i.e. pcurves, vertices, etc) and the second you do any math on them - before feeding it to the predicate - you need tracking. Predicates don’t eliminate the floating point math.
(Grain of salt and all that, I don’t really know what I’m talking about)
Edit: to be precise 'maxed out' means one weekly limit on fable used over those 4 days