Text-to-CAD open source: what exists and what's missing

I spent a weekend trying to get the Text2CAD research code running on my workstation. Two hours setting up the conda environment. Another hour downloading the model checkpoint from Hugging Face. Twenty minutes discovering the training scripts expected Linux paths I didn't have. When I finally got inference working, it generated a vaguely rectangular solid that was supposed to be a mounting bracket. The geometry was valid, technically. It also looked like something a first-year student would submit five minutes before a deadline. I closed the terminal, opened Fusion 360, and modeled the bracket in eight minutes.

That experience captures where open-source text-to-CAD stands in 2026. The research exists. The code is public. The results aren't at the point where you'd use them for work. But the pieces are assembling in interesting ways, and if you care about running this on your own hardware, controlling your data, or just understanding what's happening under the hood, it helps to know what's actually out there.

The research layer: Text2CAD#

The Text2CAD paper from NeurIPS 2024 is the most significant academic work in this space. The code is open source on GitHub (SadilKhan/Text2CAD), licensed CC BY-NC-SA 4.0, which means non-commercial use only. The dataset, model checkpoint, and training pipeline are all available on Hugging Face.

What you get: a transformer-based model that takes a text prompt and generates a sequence of sketch-and-extrude operations, trained on the DeepCAD dataset of roughly 178,000 parametric CAD models with about 660,000 text annotations. The model produces valid parametric geometry from natural language. The output is editable CAD operation sequences, not mesh.

What you don't get: production-quality output. The models in the DeepCAD dataset are geometrically simple. Mostly basic prismatic shapes, boxes, cylinders, simple mechanical parts. The Text2CAD model generates geometry within that vocabulary, and it does so at a quality level that's impressive for research but inadequate for engineering. Dimensional accuracy is rough. Complex features aren't in the training distribution. There's no UI. The inference pipeline requires Python, conda, and a GPU. It behaves like a research prototype because it is one.

Still, the fact that this exists and is downloadable matters. Two years ago, no public code could generate parametric CAD from text at all. Now you can clone a repo and do it on your own machine. The gap between this and a useful tool is large, but it's a gap between something and nothing.

OpenSCAD with LLMs: the practical option#

If I had to pick the most practical open-source text-to-CAD workflow right now, it's OpenSCAD plus a language model. Not because it's elegant, but because it actually works, within limits.

OpenSCAD is a code-based CAD tool. You write a script that describes geometry using primitives, boolean operations, and transformations. It's been around for years and it's fully open source. The output is parametric by nature: change a variable and the whole model updates. The rendering engine produces proper geometry, not mesh approximations (though you export to STL for manufacturing, which is a separate issue).

The connection to LLMs is natural. OpenSCAD scripts are code, and language models are good at generating code. You describe a part in English, the LLM writes an OpenSCAD script, and OpenSCAD renders the geometry. Several projects have formalized this workflow.

PromptSCAD is a web-based tool that uses DeepSeek v3 as its LLM backend to generate OpenSCAD code from text prompts. It renders the result in-browser using OpenSCAD compiled to WASM. Still pre-alpha, but functional. You type a description, get a script, see the geometry.

The OpenSCAD MCP Server connects OpenSCAD to AI agents via the Model Context Protocol, giving the LLM live visual feedback of what it's generating. The agent can create models, view rendered previews, and iterate. It's clever engineering, and it solves a real problem: AI generating CAD blind is like a machinist working with their eyes closed.

NL-CAD takes a multi-mode approach, supporting mechanical parts via the BOSL2 library, voxel objects, and conversational refinement. It has CLI, web, and API interfaces.

The OpenSCAD approach has real advantages. The code is inspectable and editable. The parametric relationships are explicit in the script. You can version-control the model in git. And because OpenSCAD's language is well-documented and constrained, LLMs generate surprisingly decent scripts for simple to moderate parts.

The downsides are the usual OpenSCAD limitations. The scripting language is powerful for programmatic geometry but clunky for organic shapes. There's no feature tree in the traditional sense. The export is STL, not STEP, which limits manufacturing workflows. And the LLM still makes mistakes: bad boolean operations, misplaced features, scripts that render with warnings or errors. You need to read the generated code. If you can't read OpenSCAD, you can't debug the output.

FreeCAD with AI-assisted Python#

FreeCAD is the most capable fully open-source parametric CAD program. It supports B-Rep geometry, STEP export, assemblies, FEM, and a Python scripting API that can do almost anything the GUI can do. In theory, it's the perfect foundation for open-source text-to-CAD.

In practice, the AI integration is still early. FreeCAD's Python API is extensive but inconsistent. Different workbenches have different scripting patterns. The documentation has gaps. Language models can generate FreeCAD Python scripts, but the scripts fail more often than OpenSCAD scripts because the API surface is larger and less forgiving. A wrong method name, a parameter in the wrong coordinate system, a missing recompute call, and the script fails silently or produces garbage geometry.

That said, I've had success using Claude and GPT-4 to generate FreeCAD macros for simple parts. A plate with holes. A bracket with bends. An enclosure with standoffs. The key is giving the LLM very specific instructions about the FreeCAD API and being prepared to fix the script when it inevitably gets a detail wrong. It's not a polished workflow. It's more like having a junior colleague who knows the API vocabulary but hasn't internalized the idioms.

Several community projects are working on more structured FreeCAD AI integration, including MCP servers that give language models access to FreeCAD's Python API with visual feedback. These are early and not yet stable enough for regular use, but the direction is promising. FreeCAD's architecture supports this kind of integration better than most proprietary tools, because the scripting API is a first-class citizen, not a bolted-on afterthought.

Fusion 360 MCP servers and CAD Agent#

A cluster of open-source projects have appeared connecting Fusion 360 to language models via the Model Context Protocol. These aren't text-to-CAD in the traditional sense. They're bridges that let an AI agent issue commands to Fusion 360's API.

Fusion-360-MCP-Server has around 70 GitHub stars, provides Python execution with full Fusion API access, and is available on the Autodesk app store. faust-machines' version offers 80+ tools for sketching, extrusions, assemblies, and exports. ClaudeFusion360MCP focuses specifically on teaching Claude to create models through natural language.

The advantage of this approach is that the output is native Fusion 360 geometry with full feature history. The AI isn't generating an abstract sequence that gets translated later. It's operating inside the real CAD environment, with immediate feedback about what works and what doesn't. The disadvantage is that you need a Fusion 360 license, which makes "open source" a relative term. The bridge code is open. The CAD engine is not.

There's also CAD Agent, which takes a different approach: a self-contained rendering server using build123d and MCP that lets AI agents see their CAD work in real time. The geometry is built in Python with build123d (an open-source wrapper around the OpenCascade kernel), and the agent gets visual feedback through rendered PNG images. This is fully open source, no proprietary CAD license required. Of the projects I've tested, this one comes closest to a genuinely open pipeline: open kernel, open protocol, open code.

What's missing#

The honest summary: there is no open-source tool that does what Zoo.dev does. Zoo generates B-Rep geometry from text using a purpose-built kernel (KittyCAD), with a polished UI, and outputs STEP files. Nothing in the open-source world offers that end-to-end experience.

The open-source world has pieces, not products. Text2CAD proves the research works but isn't production-grade. OpenSCAD plus an LLM is practical but limited by OpenSCAD's language and STL-only output. FreeCAD scripting works for simple cases but requires hand-holding. Fusion 360 MCP bridges produce great output but depend on proprietary software.

What's specifically missing:

A production-grade open-source B-Rep generation model trained on enough data to handle real engineering parts. The Text2CAD model is trained on 178,000 models. Image generation models train on billions of images. The data gap is enormous, and most real CAD data is locked inside companies who aren't sharing.

A user interface that non-programmers can use. Every open-source option currently requires command-line interaction, Python scripting, or both. That's fine for developers. It's a wall for the mechanical engineer who just wants to type a prompt and get a STEP file.

STEP export from AI-generated geometry without going through a proprietary kernel. OpenCascade, the open-source B-Rep kernel, can do this. Build123d wraps it in Python. But nobody has yet built a clean pipeline from text prompt to STEP file using purely open-source components that produces results competitive with commercial tools.

Where this is going#

The trajectory is clear even if the timeline isn't. The research is open. The kernels are open (OpenCascade has been around for decades). The LLMs are increasingly open. The MCP protocol creates a standard way to connect language models to CAD tools. The community is building bridges, servers, and wrappers at a pace that didn't exist a year ago.

My guess is that the practical open-source text-to-CAD workflow in the near term won't be a single monolithic tool. It'll be a pipeline: an LLM generating build123d or OpenSCAD code, a rendering server providing visual feedback, an open-source kernel producing B-Rep output, and some form of UI tying it together. The pieces exist. Someone needs to assemble them into something that doesn't require a PhD in patience to use.

For now, if you want open-source text-to-CAD, the text-to-CAD guide covers the full tool landscape including these options. OpenSCAD with an LLM is the most usable path today. FreeCAD scripting is the most capable path for anyone willing to debug Python. And the Text2CAD research code is there for anyone who wants to understand the internals and has a weekend to spend fighting conda environments. I recommend all three, for different reasons, and none of them for production work. Not yet.