Can you self-host text-to-CAD?

A manufacturing client asked me last year if they could run text-to-CAD inside their own network. No cloud. No sending geometry to someone else's servers. Their IP policy was clear: part designs do not leave the building. I said I'd look into it, spent the better part of a day investigating, and came back with the kind of answer nobody enjoys giving. "Technically, sort of, but you won't like any of the options."

That conversation happens more often than the text-to-CAD vendors probably want to admit. Defense contractors, automotive suppliers, medical device companies, anyone with real IP concerns or air-gapped environments wants to know the same thing: can I run this on my own hardware? The honest answer in 2026 is mostly no, with a few narrow exceptions that come with significant caveats.

Why self-hosting matters#

The reason isn't paranoia. CAD models contain geometry that directly represents a company's products, tooling, and manufacturing methods. A STEP file for a custom injection mold insert is worth real money. A housing design for an unreleased product is a trade secret. An assembly layout for a defense subsystem is controlled information.

Most text-to-CAD tools are cloud services. You type a prompt, it goes to a server, the server generates geometry, and it sends it back. The prompt itself often contains dimensional specifications, feature descriptions, and design intent that reveal what you're working on. Even if the vendor promises not to store your data, the fact that your geometry passed through someone else's infrastructure is a non-starter for many organizations. The text-to-CAD data safety post covers the data handling policies of major tools, but even the best policies don't satisfy an air-gap requirement.

There's also the offline use case. Factories, field locations, and classified facilities don't always have internet. A text-to-CAD tool that requires a cloud connection is useless in those environments.

What exists for self-hosting#

The options, ranked roughly by practicality.

OpenSCAD with a local LLM#

This is the most usable self-hosted text-to-CAD setup I've found. The idea: run a language model locally (Llama 3, Mistral, DeepSeek, or similar), have it generate OpenSCAD scripts from your text prompts, and render the geometry with OpenSCAD on the same machine. Everything stays local. No network call leaves your system.

The setup isn't turnkey. You need to install and configure a local LLM inference server (Ollama or llama.cpp are the common choices), set up OpenSCAD, and write or borrow the glue code that sends prompts to the model and feeds the output to OpenSCAD. The OpenSCAD AI post covers the technical details of this workflow.

Several open-source projects make this easier. NL-CAD provides a CLI and web interface for natural-language-to-OpenSCAD generation and can be pointed at a local model endpoint. The OpenSCAD MCP Server connects any MCP-compatible agent to OpenSCAD with visual feedback.

The quality depends heavily on the local model. Llama 3 70B generates decent OpenSCAD for simple parts. Smaller models struggle with correct boolean operations and parameter placement. The best results I've gotten locally are still noticeably worse than what you get from a cloud model like Claude or GPT-4, because the local models are smaller and less capable at code generation. But the output stays on your machine, which is the whole point.

The limitations are the same as any OpenSCAD workflow: STL output only (no STEP), limited to geometry that OpenSCAD can express (no freeform surfaces, no feature tree), and you need to be able to read and debug OpenSCAD code when the model gets something wrong.

Text2CAD research code#

The Text2CAD model can be run entirely locally. The code is on GitHub, the model checkpoint is on Hugging Face, and the inference pipeline is Python. Once you get it running (which takes some determination and a GPU), you have a fully self-hosted system that generates parametric CAD operation sequences from text.

The problem is that the output quality isn't production-grade. The model was trained on the DeepCAD dataset, which contains simple prismatic parts. The generated geometry is approximate in dimensions and limited in complexity. There's no user interface. The inference is batch-mode Python scripts.

You could absolutely run this inside a corporate network. Whether you'd want to depends on whether "technically generates CAD from text" meets your bar. For research, experimentation, or as a starting point for a custom pipeline, it has value. For generating parts that engineers would use, it's not there yet.

The license is CC BY-NC-SA 4.0: non-commercial only. If your self-hosting use case involves a business generating parts for products, you're already in a licensing gray area.

FreeCAD with local AI#

FreeCAD runs locally and has a Python scripting API. If you pair it with a local LLM, you can generate FreeCAD Python macros from text prompts and execute them inside FreeCAD. The output is real B-Rep geometry with STEP export, which is more useful for engineering workflows than OpenSCAD's STL.

The difficulty is reliability. FreeCAD's Python API is extensive but has enough quirks that local LLMs (which are less capable than cloud models) produce scripts that fail frequently. Wrong method signatures, missing recompute calls, coordinate system confusion. I'd estimate that about half the scripts generated by a local 70B model for FreeCAD need manual fixes, compared to maybe a quarter when using Claude or GPT-4 through the cloud. That failure rate makes it hard to recommend for regular use.

A few community projects are building FreeCAD AI plugins and MCP servers that could eventually support local model backends. These are early, but the architecture is right: FreeCAD as the open kernel, a local model as the brain, and an MCP server connecting them with visual feedback.

Build123d with a local agent#

Build123d is a Python CAD library built on OpenCascade, the same open-source kernel that FreeCAD uses. It produces B-Rep geometry and exports STEP. The CAD Agent project already wraps build123d in an MCP server that gives AI agents visual feedback of their work.

In principle, you could point CAD Agent at a local LLM instead of a cloud model. The rendering server and build123d run locally. The only external dependency is the language model, and that can be replaced with a local one. In practice, I haven't tested this specific configuration extensively, and the code generation quality with local models is likely the weak link, same as with FreeCAD scripting.

This is probably the most promising fully-open self-hosted pipeline: local LLM, build123d for geometry, OpenCascade as the kernel, STEP as the output, and visual feedback through the rendering server. It's not packaged as a product. You'd be assembling it yourself.

What you can't self-host#

Zoo.dev is cloud-only. The KittyCAD geometry kernel that powers it is proprietary. There's no self-hosted version and no announced plans for one. This is the most capable text-to-CAD tool on the market, and it is not available for on-premise deployment.

AdamCAD is cloud-only. The generation happens on their servers.

Any tool that uses OpenAI, Anthropic, or other cloud LLM APIs requires network access to those providers, which means your prompts (and any design information they contain) leave your network.

The gap#

The fundamental problem is that the best text-to-CAD results require large models running on significant compute infrastructure, and most organizations don't want to set up and maintain that. A 70B parameter model needs a serious GPU or a cluster of consumer GPUs. A smaller model generates worse CAD. There's no magic middle ground where you get cloud-quality generation from a model that runs on a workstation quietly.

The kernel side is actually in reasonable shape. OpenCascade exists. Build123d wraps it nicely. STEP export works. The geometry creation pipeline can be fully local and open source. The bottleneck is the language model: the quality of the code generation, the ability to recover from errors, and the capacity to handle complex prompts. That's where the gap between local and cloud models hits hardest.

Where this leaves enterprise#

If you need text-to-CAD and your geometry cannot leave your network, you have two practical options today. OpenSCAD with a local LLM for simple parts with STL output. Or FreeCAD/build123d scripting with a local LLM for B-Rep geometry with STEP output, accepting that you'll debug a lot of broken scripts.

Neither option is a product. Both are workflows you assemble and maintain yourself. Neither produces results competitive with what Zoo.dev does in the cloud.

The text-to-CAD open source ecosystem is improving, and the pieces for a good self-hosted pipeline exist. But "the pieces exist" and "it's ready for enterprise deployment" are different statements, and I'd be lying if I said the second one was true. For now, the companies that need self-hosted text-to-CAD are stuck choosing between data protection and output quality. The tools haven't solved that tradeoff yet.