Why I built solidifai: parametric CAD through Claude Code

My 3D printer runs every week. Fusion 360 gets opened maybe twice a month, and every session starts the same way: a blank viewport, a dozen half-remembered keyboard shortcuts, and ten minutes of relearning where the tools live before I can even start sketching.

I wrote about my 3D printer as the most useful tool in my office, and that still holds. The printer is not the bottleneck. Getting a model into the printer is. For parts someone else already designed, Printables has me covered. For custom parts, the ones that make owning a printer actually worth it, everything goes through CAD. And CAD is a skill that decays fast when you only use it twice a month.

So I built solidifai, a desktop CAD tool where the modeling happens by talking to the coding agent I already use every day. I describe a part in the embedded terminal, Claude Code writes the geometry, and a real parametric solid shows up in the viewport a few seconds later.

The blank viewport problem

Fusion 360 is genuinely good software. When I need precise control over a part, nothing I have used comes close. The problem is not Fusion. The problem is where every part starts: an empty viewport and a mental model I have to rebuild from scratch each session.

Most of my parts are not hard. A bracket to mount a Raspberry Pi under a shelf. A cable clip sized for my desk. A case for a LoRa board with two screw holes and a cutout for the antenna. I know exactly what I want before I open the software. The geometry is fully formed in my head, usually with dimensions. What follows is anywhere from 15 minutes for a simple clip to most of an evening for a case with standoffs and cutouts, all of it spent translating something I could describe in two sentences into sketches, constraints, extrudes, and fillets.

That translation step is exactly the kind of work I stopped doing for software. I spend my days directing agents instead of typing every line myself. Claude Code is my primary harness for personal projects. I describe the outcome, the agent works out the implementation, and I review and steer. It felt increasingly absurd that I worked this way for code but was still hand-sketching every 2D profile for a plastic bracket.

CAD as code already existed

The insight that made solidifai feel buildable is that code-based CAD is an old, solved idea. I mentioned OpenSCAD back in my 3D printer post as "surprisingly useful for parametric designs." The modern version of that idea is build123d, a Python library on top of the OpenCascade kernel, the same B-rep geometry engine that powers FreeCAD. You write Python, you get real solids. Not meshes, actual boundary representation geometry that exports to STEP and opens cleanly in any serious CAD package.

If the model is code, an agent can write it. Claude Code is very good at writing Python. It does not need to learn a modeling UI, and neither do I.

The obvious first move is to just ask Claude Code to write build123d scripts in a plain terminal. That works, sort of. It also runs into three problems fast:

The agent is blind. It writes geometry it can never see. When a fillet fails or a hole lands in the wrong face, the agent gets a Python traceback at best and silence at worst. You become the renderer, describing what looks wrong in words.

You become the render loop. Every iteration means running the script, opening the output in a viewer, looking at it, and typing feedback. That is the same clipboard-shaped bottleneck that made me build Omnibase for databases. I was the slow, error-prone pipe between two systems that should talk directly.

Nothing is parametric at runtime. The script might define a wall_thickness variable, but changing it means editing code and re-running. The whole point of parametric CAD is dragging a value and watching the part update.

solidifai exists to fix those three things and nothing else.

A harness, not another AI CAD service

There is a wave of AI CAD tools right now. Zoo does text-to-CAD with their own trained model. AdamCAD wraps prompt-driven modeling in a browser app. The pattern is consistent: a chat box bolted onto a modeler, with the vendor's model behind it and the vendor's subscription in front of it.

I did not want another model with another bill and another context window that knows nothing about me. I already pay for Claude Code. It already has my preferences, my instincts about it are already calibrated, and it is already the tool I trust to do multi-step work. What was missing was not intelligence. It was plumbing.

So solidifai ships no model and holds no API keys. It is a harness. Open the app and you get an embedded terminal sitting in a pre-provisioned workspace. Type claude (Codex and opencode work too) and the agent wakes up already knowing how to model, because the workspace comes wired with an MCP server, a CLAUDE.md, and a set of skills covering the modeling conventions. I have written about MCP before, and this is the same idea Omnibase applied to databases: give the agent direct tool access and get out of the loop.

The architecture looks like this:

graph TD
    T[Embedded terminal running Claude Code] -->|MCP tool calls| B[solidifai-cad MCP bridge]
    B -->|local RPC| E[Warm build123d engine]
    U[UI: sliders, export, measure] -->|same RPC| E
    E -->|writes model.glb + model.json| W[Artifact watcher]
    W -->|model-updated event| V[three.js viewport]

Two decisions matter here.

The app owns the engine. One long-lived Python process runs build123d and serves both the agent and the UI through the same render path. OpenCascade takes seconds to import, so the engine stays warm. What the agent builds, what I see in the viewport, and what gets exported are the same geometry, byte for byte. There is no "the agent thinks it made X but the file contains Y" gap.

The agent can see its own work. The MCP tools include capture_views, which renders the model from any camera angle, or a tiled contact sheet of all angles at once. The agent builds a part, looks at it, notices the hole is on the wrong face, and fixes it before I ever say anything. Watching an agent self-correct from a screenshot of its own geometry was the moment this project stopped feeling like a toy.

The shell is Tauri 2 with a React and three.js frontend. After writing about why I prefer Tauri over Electron, it was the default choice, and it earned its keep here: the app also acts as PTY host for the terminal, supervises the Python engine, and watches the filesystem for new geometry, all from the Rust side.

What the loop actually feels like

A session looks like this. I open a workspace, wait for the engine pill to read ready, and type what I want:

Make a mounting bracket for a Raspberry Pi 4: 4 M2.5 holes at 58 x 49 mm spacing, 3 mm base plate, two countersunk M4 holes on a side flange for wall mounting.

The agent writes model.py through the execute_script tool, the engine rebuilds, and the bracket appears in the viewport with dimensions annotated. Hole spacing wrong? I say so in plain language. Wall too thin for the printer? The agent exposed base_thickness as a parameter, so I drag the slider from 3 to 4 mm and the model re-runs live. No prompt, no re-render dance.

This is the part I underestimated before building it. I assumed the value was in the first generation, the described-part-appears moment. The actual value is in iteration. Most of my tweaking happens either by dragging sliders or by telling the agent "make the flange 5 mm wider," and both paths hit the same warm engine. The friction between "I want it slightly different" and "it is slightly different" drops to near zero.

Every build lands in a git-backed history with undo and redo, and model.py is a real file in a real folder. I can commit it, diff it, or hand-edit it. The workspace is mine, not trapped in an app database.

When the part is done, I export STL or 3MF and send it to the slicer. Total time for a bracket like that one: a few minutes, most of it me deciding what I actually want.

Good enough is the point

Here is the honest framing of what solidifai is for, because "AI designs your parts" oversells it.

For most of what I print, the agent's output plus a few parameter tweaks is the finished part. Brackets, clips, cases, mounts, spacers. Functional geometry with known dimensions. This covers the overwhelming majority of my printing, and for this category I never open Fusion at all.

For the parts that need real refinement, complex surfacing, tight assemblies, anything where I want to push and pull geometry by hand, solidifai is the starting point instead of the blank viewport. The engine produces genuine B-rep solids, so I export STEP, open it in Fusion 360, and continue from a model that already has the bones right. That is a very different experience from importing an STL mesh, which arrives in Fusion as an uneditable blob of triangles.

Either way, the blank viewport is gone. I start from something in both cases. The question is just whether the something is 95% done or 70% done.

Where it stands

solidifai is an early MVP. I built and validated it on macOS. The release pipeline produces Windows and Linux installers too, but macOS is the only platform I have tested end to end, so treat the others as experimental for now. Builds are not yet OS code-signed, which means a one-time Gatekeeper or SmartScreen prompt on first launch.

After Omnibase, this is my second open source project, and the habits carried over: Apache 2.0, conventional commits, automated releases with release-please, CI that runs the full gate on every push. Omnibase taught me that for open source, the README and the error messages are as much the product as the code. solidifai got that treatment from day one.

Agents still make geometry mistakes. A chamfer on the wrong edge, a boolean that eats the wrong solid. The self-inspection tools catch a lot of it, and the failed-build recovery skill catches more, but this is not a tool that removes you from the loop. You review parts the way you review code. If you already work that way with an agent, it feels natural. If you expect a vending machine, you will be disappointed.

If you have a 3D printer, a terminal-based agent like Claude Code, and a folder of parts you never modeled because opening CAD felt like too much ceremony, give it a try. Describe the part you have been putting off. The viewport will not be blank.

Sources

• solidifai on GitHub
• build123d documentation
• Model Context Protocol
• Tauri
• Zoo Text-to-CAD