OpenSCAD + AI: the text-to-CAD workflow nobody talks about

I've been using OpenSCAD on and off for about eight years, mostly for parametric enclosures, jigs, and the kind of small utility parts that don't justify opening Fusion 360. The workflow has always been the same: open a text editor, write geometry in code, hit F5 to preview, swear at a boolean union, fix it, export STL, print. It's not glamorous. The preview window looks like it was designed in 2004, because it was. The language has no classes, no proper error messages, and a rendering engine that punishes you for ambitious geometry by simply refusing to finish.

But here's the thing nobody in the text-to-CAD conversation seems to have noticed: OpenSCAD has been a text-to-CAD tool this whole time. The input is text. The output is geometry. The entire model is a script. There's no feature tree, no click-based modeling, no hidden state. Everything is in the code, and code is exactly what language models are good at writing.

When I first asked ChatGPT to write me an OpenSCAD script for a cable clip, sometime in early 2024, I expected garbage. What I got was a working script with parametric variables for cable diameter, wall thickness, and mounting hole size. It compiled on the first try. The proportions were off, the snap arm was too thin, and the base needed a wider foot, but the structure was correct and every dimension was a variable I could edit. I tweaked three numbers and had a printable part in under ten minutes. That was the moment I started paying attention.

Why OpenSCAD is the natural fit#

The text-to-CAD space has plenty of tools generating geometry from text prompts. Zoo.dev generates B-Rep solids from descriptions. Research models like Text2CAD generate parametric operation sequences. Various MCP servers connect language models to Fusion 360 and FreeCAD. These all work, to varying degrees. But they all face the same fundamental problem: the AI generates geometry it can't see, can't debug, and can't reason about structurally.

OpenSCAD sidesteps this entirely because there's no gap between the representation and the generation. The model is code. The AI generates code. The output is directly editable in the same format it was created in. There's no translation layer, no compiled binary representation, no opaque feature tree. If the AI generates a cylinder with cylinder(h=20, d=10); and the height is wrong, you change the 20 to 25. If the AI puts a hole in the wrong place, you adjust the translate() values. The debugging workflow is the same whether a human or an AI wrote the script.

This matters more than it sounds like it should. With other text-to-CAD tools, when the output is wrong, your options are: re-prompt and hope for better, or import the geometry into a CAD tool and fix it there. With OpenSCAD, you just edit the script. The AI's output is your working file. There's no import step, no format conversion, no loss of parametric intent.

OpenSCAD's language is also surprisingly LLM-friendly. The syntax is small and well-defined. The primitives are simple: cube, cylinder, sphere. The operations are straightforward: union, difference, intersection, translate, rotate, scale. The language has been documented for years across tutorials, forums, and the official manual. It shows up extensively in LLM training data. ChatGPT, Claude, and even smaller local models generate syntactically valid OpenSCAD more consistently than they generate Python scripts for FreeCAD or macro code for SolidWorks.

What the workflow actually looks like#

The simplest version: you describe a part to an LLM, get back an OpenSCAD script, paste it into OpenSCAD, hit F5, and look at the result. If it's wrong, you either edit the script directly or tell the AI what to fix. This is the ChatGPT + OpenSCAD workflow, and for simple parts it works surprisingly well.

The more advanced version uses tools that close the feedback loop. PromptSCAD runs the full cycle in a browser: you describe a part, DeepSeek v3 generates the script, and OpenSCAD compiled to WASM renders the result in real time. Still pre-alpha, but functional. OpenSCAD Studio provides a desktop and web editor with Claude and GPT integration, live preview, and syntax highlighting.

The most interesting development is the OpenSCAD MCP server ecosystem. Multiple projects now connect OpenSCAD to AI agents via the Model Context Protocol, giving the LLM the ability to generate code, render previews, and see the result. The AI writes a script, OpenSCAD renders it, the AI looks at the rendering and decides what to change. This is the workflow that makes text-to-CAD actually iterative instead of a guess-and-check loop.

NL-CAD takes a multi-mode approach, supporting the BOSL2 library for mechanical parts, voxel objects, and conversational refinement through CLI, web, and API interfaces. BOSL2 is worth mentioning because it extends OpenSCAD's vocabulary significantly, adding proper screws, threads, gears, and snap connectors that the base language can't handle well.

Where the geometry holds up#

OpenSCAD with an LLM works well for a specific category of parts: parametric, prismatic, mechanical components built from boolean operations on simple solids. The kind of thing you'd 3D print, laser cut, or CNC from stock.

Enclosures, brackets, mounts, standoffs, clips, spacers, simple housings, cable management parts, test jigs, alignment fixtures, PCB mounting plates, sensor brackets, fan adapters, battery holders. I've generated usable versions of all of these. Not perfect versions. Usable starting points where every dimension is a variable I can adjust.

The sweet spot is parts with clear geometric logic. An enclosure is a box minus a slightly smaller box. A bracket is two intersecting plates with holes. A standoff is a cylinder with a smaller cylinder subtracted from the center. These map cleanly onto OpenSCAD's boolean operations, and LLMs generate them reliably because the geometric intent is close to the code structure.

Parts that need exact dimensions relative to existing hardware (PCB mounting holes at specific positions, bolt patterns matching a standard) work well as long as you specify the dimensions in the prompt. The AI doesn't know your PCB layout, but if you tell it "four M3 mounting holes on a 58mm by 48mm rectangular pattern, centered on a 70mm by 60mm plate," you'll get exactly that.

Where it falls apart#

OpenSCAD has real limitations, and AI doesn't fix them.

Organic shapes. Anything with complex curves, sculpted surfaces, or freeform geometry is painful in OpenSCAD regardless of whether a human or an AI writes the code. The language doesn't have splines. Smooth curves require hulling many small primitives, which is slow to render and ugly to read. If your part has an ergonomic grip or an aerodynamic profile, OpenSCAD is the wrong tool and adding AI doesn't change that.

Export format. OpenSCAD exports STL, 3MF, AMF, OFF, DXF, and SVG. It does not export STEP. For 3D printing this doesn't matter. For manufacturing workflows that require STEP, it's a hard stop. No amount of AI magic changes the fact that OpenSCAD produces tessellated geometry, not B-Rep solids. If you need a STEP file, you need a different tool.

Complex assemblies. OpenSCAD has no assembly concept. You can model multiple parts in one script using modules, but there are no constraints, no mates, no interference checks. The AI can generate a box and a lid in the same script, but they're just geometry floating in space. If you need assembly features, you're working around the language's limitations, and the AI inherits those limitations.

Threading and fine mechanical features. OpenSCAD can generate thread-like geometry using libraries like BOSL2, but the results are approximations useful for 3D printing, not for precision machining. The AI will write BOSL2 thread calls if you ask, but the output is decorative thread geometry, not real thread form.

The AI also introduces its own failure modes. Boolean operations are the most common problem. The AI will occasionally generate geometry where two bodies share a face exactly, causing OpenSCAD to produce warnings or garbage output. It'll place features slightly off-axis, creating tiny geometric slivers. It'll nest difference() operations in ways that produce unexpected results because the order of subtraction matters and the AI doesn't always get the intent right. You learn to recognize these patterns quickly, but they require reading the generated code, not just looking at the preview.

The hidden advantage: version control#

One thing I didn't expect to care about but now consider a genuine advantage: OpenSCAD scripts work perfectly with git. The model is a text file. You can diff changes, review modifications, track history, branch experiments, and merge updates the same way you manage code. This doesn't matter for a one-off bracket. It matters a lot if you're maintaining a library of parametric parts, collaborating with someone, or want to track why a dimension changed.

AI-generated OpenSCAD scripts fit neatly into this workflow. I keep a repository of utility parts, each as a .scad file with a corresponding prompt file documenting what I asked the AI to generate. When I need to modify a part, I can either edit the script directly, re-prompt the AI with adjustments, or both. The history stays clean and readable because the diff shows exactly what changed and why.

Try doing that with a Fusion 360 .f3d file. The version history is inside Fusion's cloud, tied to their account system, and opaque to every tool outside their ecosystem. OpenSCAD's version control story is accidental, but it's better than what any commercial CAD tool offers for AI-generated content.

The ecosystem is growing fast#

A year ago, using OpenSCAD with an LLM meant copy-pasting text between a chat window and a text editor. Now there's a browser-based tool, multiple MCP servers, a desktop editor with AI integration, and libraries like BOSL2 that extend what the language can describe. The community around this workflow is small but active, and the pace of development is accelerating.

The text-to-CAD open source landscape has many moving pieces. Research models, FreeCAD scripts, Fusion 360 MCP bridges. But the OpenSCAD path is the only one where the entire pipeline is open, the output is editable code, and the workflow doesn't depend on a proprietary CAD engine or a commercial API. That combination matters for hobbyists, for educators, and for anyone who wants to understand and control what the AI is actually producing.

The honest assessment#

OpenSCAD + AI is not the future of CAD. It's not going to replace SolidWorks, or Fusion 360, or even FreeCAD. The language is too limited, the geometry too constrained, the export formats too restricted for professional mechanical engineering work. If you need STEP files, assemblies, simulations, or organic surfaces, look elsewhere.

But for what it does, it works better than anything else in the text-to-CAD space right now. Parametric code you can read, edit, version-control, and regenerate. A workflow where AI assistance feels natural because the medium is already text. An ecosystem that's fully open source, runs locally, and doesn't require a subscription or an API key if you're using a local LLM.

I still model most of my professional work in Fusion 360. But my jig library, my cable management parts, my one-off brackets and test fixtures? Those are all OpenSCAD scripts now, half of them started by an LLM, all of them edited by hand. It's the quietest success story in text-to-CAD, and I suspect it'll stay quiet, because it doesn't have a marketing department. Just a text editor and a preview window that looks like it hasn't been updated since the first Obama administration.