OpenSCAD beats CadQuery on the hardest CAD task, but both hide silent failures
Benchmark: CadQuery vs. OpenSCAD for agentic CAD work
ModelRift ran six AI agents on three CAD tasks using OpenSCAD and CadQuery. Both produced printable parts, but OpenSCAD solved a true helical thread in one version and 43 ms, while CadQuery needed three versions and silently dropped a core cylinder due to exact tangency. The real danger: both tools sometimes report success on broken geometry, so external mesh validation is essential.
`union()` silently discarded the core cylinder because the thread root sat exactly on the core radius. Exact tangency along a helical curve, and OCCT dropped a solid without a word.
- rounce
> Both toolchains shipped. The difference is in how they fail.
Yuck, this style of LLM output is awful, it’s horrible to read and does a lot to say absolutely nothing.
- dofm
None of the "findings" here really needed an AI experiment to do it:
- "CadQuery fails loudly and early... OpenSCAD fails silently and late"
This should be obvious, from the documentation, from the way geometry construction works. OpenSCAD has no sense of failure where one shape means another won't work; you're just drawing the equivalent of 3D pixels in space. It will always potentially-meaninglessly succeed if the syntax is OK.
- Renders caught nothing that mattered
Objects with hollows are not going to show their major problems this way.
- CadQuery can be interrogated, OpenSCAD cannot
Isn't this explicit from the documentation of both? One works by iteratively building on top of a previous result that can be stored in a variable; the other doesn't.
- OpenSCAD renders have no concept of a part edge
Again — this should be explicit from the documentation, which describes no methods for operating on edges (and largely from the fact that it is declarative).
- Speed favours OpenSCAD, and it barely matters
Yes, being faster is no good if things are wrong.
- "What decides it is verifiability rather than expressiveness, and CadQuery leads there by a wider margin than the syntax difference suggests."
Yes, because the difference is semantic. Which you can get from the documentation. Building iteratively on the basis of existing geometry is inherently more verifiable, because stuff that can't work won't work.
Honestly do people not try learning CAD before they try to build an AI tool […]
- rao-v
I tried modifying the provided CadQuery skill to work with build123d with an agent (surprisingly gemini pretty good at this) and it produced very good results (possibly better than the reported CadQuery/OpenSCAD results after taking a little care to avoid leaking the benchmark pass/fail criteria). Worth a try if you are interested in this space.
I like build123d simply because it can export proper STEP (like CadQuery) but has a nicely python friendly design.
- darkteflon
I’ve been playing in this space as a moderately experienced hobbyist - mainly for 3D printing functional parts.
I’m using a single repo for all my models and Claude with build123d (plus a VS Code viz extension). Over time, I’ve built up a little folder of useful skills and I’m generally getting satisfactory results.
That said, I have had my eye on CadQuery and am looking for an excuse to try it. For those in the know: how does it compare to build123d?
- YuechenLi
Oh, on this topic, I've actually built a geometric CAD kernel with GPT that I think is pretty promising and in my biased opinion, a bit more advanced than OpenSCAD or CadQuery's OCCT backend, anybody here want to clone the repo to give it a try with their Claude/GPT to see they do better on my thing?
https://github.com/yuechen-li-dev/Aetheris/
It's still kinda buggy but they are actively getting fixed, but Claude and GPTs seemed to work better with my current design than other CAD stacks. Still haven't added threads yet, so can't speak for T3, but generally speaking the generated parts are pretty good quality, and I also got fillets/chamfers working so that's a plus.