CADQuery and AI: Automating Parametric 3D Printing from Text

Watch (28:21)

Overview

How AI plus CADQuery turns text descriptions into parametric CAD scripts and STL files - and where the workflow quietly breaks.

Full transcript (from the video)

I want to start with a claim that anyone who owns a 3D printer feels in their bones, even if they have never said it out loud. The printer is not the bottleneck. The slicer is not the bottleneck. The Bamboo Lab Studio I have downstairs will turn an STL into a working print in under a minute of slicing and a few hours of patient extrusion. The actual bottleneck, the one that decides whether a project gets made at all, is the CAD step.

The hour you spend in Fusion 360 dragging dimension lines around. The afternoon you spend in on shape figuring out why your filt failed. The evening you spend in Blender pushing vertices for a part that needed to be parametric. 3D printing has been waiting for AI to arrive specifically at the modeling step. And the way I want to talk about that today is through a Python library called CAD query and a small custom command line tool we are going to design around it.

CAD query is the library that makes the rest of this talk possible. So let me introduce it properly. CAD query is an open-source Python package that describes the way the rest of us describe data pipelines with code instead of a graphical user interface. Under the hood, it sits on top of Open Cascade, the same industrial geometry kernel that FreeCAD uses. So, the math is grown up even if the API is friendly.

The model on screen is a complete CAD query script. Five lines including the import. It defines a 60x4x5 mm plate, hops onto the top face, and drills a 6 mm hole. When you run that script, you get back a real solid and you can write it to STL or step and walk it straight into your slicer. A part is a Python file.

You diff it, you commit it, you import it from another file. That last property that a CAD model is text is the entire reason AI can finally help. There are dozens of CAD packages in the world and AI does an okay job in most of them. The CAD query is the one that fits AI assistance like a glove. And it is worth understanding why before we go any further.

The first reason is that the model and the program are the same thing. The script is the part. There is no separate binary file, no proprietary save format, no design tree hidden inside a database. A language model can read the script, edit the script, and write a new script and the geometry follows automatically. The second reason is that everything is parametric.

If I change a single number near the top of the file, the whole part regenerates around that change. The third reason is that errors look like Python errors. A failed boolean union throws an exception with a stack trace which the model can read and reason about instead of producing a corrupted step file with no warning. And the last reason, which sounds small but matters, is that a CAD query script reruns identically on any machine. You do not need a license server, a cloud project, or even a UI.

That makes it perfect for an automated pipeline. I want to be fair to the alternatives because each of them is a real piece of software with real users and I do not want anyone to think CAD query is the right tool for every job. Fusion 360 from Autodesk is genuinely excellent at paramet modeling and has a Python API, but the canonical part lives in a proprietary cloud project not in a script you can hand to a model. On shape is even more cloudnative with great real-time collaboration, but you cannot pip install it and you cannot run a two build of an onshape model on a server without their service. Blender is the open-source giant of 3D, but it is meshbased and artist first, and forcing it into a parametric mechanical workflow bites the tool.

Frecad is parametric, free, and locally installable, and it has a Python console, but its API is genuinely harder to drive cleanly, and its execution model is closely tied to its UI. CADQuery sits in a small but important sweet spot. It is scriptable, parametric, fully local, and trivially drivable from a server, a notebook, or a chat session. That is exactly the shape an AI workflow needs. Before we get to the AI part, I want everyone to leave with a working mental model of how a CAD query script reads.

Because once you have that model, the rest of the talk falls into place. Every script begins with a work plane, which is a fancy way of saying a local coordinate frame plus a sketch surface. From there, you chain operations together with method calls. Box and cylinder make primitives. Hole and pocket Billy and chamfer round or bevel edges.

Cut, union, and intersect do boolean operations between. The trickiest piece for newcomers is the selectors. Strings like greater than Z mean the topmost face along the Z-axis and pipe Z means edges parallel to Z. Once you have selected some, the next operation applies to that selection. The example on screen builds a flanged plate with four corner holes and rounded vertical edges in seven chained calls.

That same chain reads almost like English to anyone who has used the library for a week, which is exactly why it is friendly to a language model. If you want to be productive in CAD query quickly, focus on a small kit of operations and resist the urge to learn the whole library on day one. The first kit is primitives box, cylinder, sphere, and revolve handle the bulk shape of almost every functional part you will print. The second kit is work planes. The whole point of CAD query is that you can hop onto an arbitrary face of an existing solid, drop a sketch on it and extrude or cut from there.

And that hopping pattern is what makes parts feel composed instead of carved. The third kit is the boolean operations. Union glues solids to cut subtracts the second from the first. Intersect gives you the overlap. Almost every multi-piece part is a sequence of unions and cuts at heart.

The fourth kit is the finishing operations fillet and chamfer which take a sharp edge and round or bevel it. These are not cosmetic. A printed part with a sharp internal corner will crack along that corner. Fillers are how you turn a CAD model into a part that survives use. Sketches and selectors deserve a slide of their own because they are the two parts of CAD query that take the longest to internalize and they are also the two parts that an AI can most often gets wrong on a first try.

A sketch is a two-dimensional outline drawn on a work plane that gets turned into a three-dimensional feature by an extrude, a cut, or a hole call. The sketch lives on whatever face the previous operation selected. Selectors are CAD query's mini language for picking faces, edges, or vertices out of a solid so that the next operation knows where to land. Greater than Z means the face that points the most along positive Z. Pipe Z means edges parallel to the Zaxis.

Percent circle means circular edges, which is how you grab the rim of a cylinder for a fillet. When I have watched language models write CAD query and produce broken parts, 90% of the failures are not in the high-level structure. They are in the selector strings. The model picks an edge that does not exist or it picks too many edges and the operation either errors, modifies geometry it should not touch. That observation is going to drive the design of our CLI.

If you sit down today with a chat assistant and ask it for a CAD query script for a printable part, you will get something back almost immediately. And about half the time, it will work on the first try. The other half of the time you will hit one of four specific failure modes and they are worth understanding because the CLI we build later is designed exactly to make these failures rare. Failure one is selectors that miss. The model selects an edge that does not exist on the current solid and the operation either errors or worse applies to a different edge that happens to match.

Failure two is bounding box drift. You ask for a small edit. The model rewrites a chained block and the resulting part is silently the wrong size. Failure three, and this is the deepest one, is that the model cannot see the part. It writes the script blind, runs it in its head, and has no idea whether the result actually looks like what you ask for.

Failure 4 is manifold breakage. A fillet radius that is too large for the surrounding geometry produces a self-intersecting solid which prints none of these are CAD query's fault. They are the natural consequence of asking a text model to do geometry without help. The help is what we are about to build. Here is the design move that turns the situation around.

Instead of asking a language model to write raw CAD query, we give the model a small command line tool whose verbs are designed to be safe to call. Each verb wraps a curated CAD query template. Each verb takes named parameters with units. Each verb runs the geome validates that the result is a manifold solid of roughly the dimensions the caller expected and writes an STL to disk. The model never has to write a selector string.

The model never has to remember whether to call cut or boolean_cut. The model just chooses a verb and fills in numbers. That is a task that modern language models are extremely good at because it is the same shape as filling in a function call. The output is a clean STL plus a oneline confirmation that says what you actually got. If you wanted a 60 mm bracket and the verb returned a 45 mm bracket, the line on screen would tell you and either you or the model can react to that fact.

The CLI is the contract. English goes in, a printable solid comes out, and the CAD query details stay safely on the inside. Let me make the architecture concrete so anyone listening could go home and build a first version of this themselves. The CLI has three layers and the separation matters. The first layer is the verb registry.

Each verb is a small Python function that [clears throat] takes parameters and returns a CAD query solid. And the verbs are deliberately curated for the kinds of parts you actually print at home. Bracket, stand, enclosure, tray, knob, adap. The second layer is the validator. Before a part is allowed out of the CLI, it gets checked.

The bounding box must roughly match the collar stated dimensions. The solid must be manifold, which means it has a clean inside and outside with no self-intersections. The minimum wall thickness must be above whatever your printer can reliably extrude, typically 0.8 mm. The third layer is the exporter. It writes the STL and alongside it a small JSON manifest that records which verb was called with which parameters.

That manifest is what lets you regenerate the part later, audit what the AI made or hand the same parameters to a different verb. The AI front end never reaches around the CLI to call CAD query directly. It always goes through this stack. That single discipline is what makes the whole thing reliable. Let me walk through one full round trip from English to printable file because seeing the trip end to end makes the architecture click.

You ask the assistant for a desk stand for a tall phone tilted back with a cable cutout. The model reads your sentence, picks the phone stand verb out of the registry, and fills in the parameters. Device height 165 mm, which is a 6 1/2 in phone. Device thickness 9 mm, which is roughly any modern phone with a case on. Angle 65°, which the model knows from your text.

Base depth 70 mm, which the model picked because it knows the stand needs to be deeper than the two. Phone is tall when tilted. Cable cutout 12 mm, which is enough for a USBC plug. The CLI builds the solid in CAD query, validates that the result is manifold, verifies the minimum wall thickness is above your printer safe minimum, and writes the STL plus a manifest. You get back a single confirmation line telling you the bounding box and the print orientation it expects from your sentence to a file you can drag into Bamboo Studio is on a warm machine about 3 seconds.

That is the trip the CLI exists to make routine. This slide is the one I most want people to take seriously because validation is the difference between a CLI that occasionally produces garbage and a CLI you can actually trust to feed your printer unattended. There are four checks worth doing on every generated part. The first is the bounding box. After the model is built, you measure its width, depth, and height, and you compare those numbers to what the caller asked for.

If the bracket came out 10 times bigger than you ask for, somebody made a units mistake, and the bounding box catches it instantly. The second is the manifold check. A manifold mesh has a well-defined inside and outside with no self-intersection, no holes, and no flipped normals. The slicer will reject anything that fails this, but you want to catch it earlier. The third is wall thickness.

Every printer has a minimum wall it can reliably extrude, usually around 1 mm for a standard nozzle. If any feature is thinner than that, the part will fail to print. The fourth is overhang angle. Anything tilted further than roughly half a right angle from vertical needs support material to print successfully. When all four checks pass, you have an STL that will probably print on the first try.

When any of them fail, the CLI tells you exactly which one, and the AI can iterate. The loop is the secret that makes everything reliable, and once you build it, you wonder how you ever lived without it. The model proposes parameters and calls the CLI. The CLI tries to build the part. If the build or the validation fails, the CLI returns a structured failure record in JSON that names exactly which check failed and why the fillet was too large for the geometry.

The wall under that hole was too thin. The bounding box came out the wrong size because the angle parameter was outside the verb's valid range. The model reads that failure reasons about which single parameter to change and tries again. Crucially, the model does not rewrite the whole script. It just nudges one number.

Two or three iterations is normal for any non-trivial part, and each iteration cost you a few hundred tokens and a second of cade query time. After three iterations, you have a part that has passed every printability check we know how to write down. The first time you watch a park get built and validated and refined entirely without a human dragging a single dimension line, you start to feel why this is a real shift in how home manufacturing is going to work. A short detour on file formats because every newcomer trips over this exactly once and then never again. STL is a triangle mesh.

It describes the surface of your part as a soup of little triangles with no notion of which face used to be a circle or which edge used to be a fillet. Every slicer in the world reads STL and every printer in the world ultimately consumes a sliced STL. So STL is what you produce when the goal is to print. 3MF is a newer format championed by Bamboo Lab and Microsoft that wraps an STL with metadata like color, material, and build plate position. If you are sending a part to Bamboo Studio, 3 MF preserves more of your intent than a bare STL.

Steep is a different beast entirely. A step file preserves the parametric structure of the model. The cylinder is still a cylinder. The fillet is still a fillet. and another CAD tool can edit the part as if it were native.

If you are collaborating with someone who uses Fusion or Solid Works, send them step. The CLI writes STL by default because that is the printerbound path, but it can also export step whenever you want a clean handoff. This is where the workflow rejoins the path that anyone who has used a Bamboo Lab printer already knows. Bamboo Studio, the slicer that ships with the X1, the P1, and the A1 line, expects an STL or a 3MF as input. The CLI writes both.

You import the file. You pick the printer profile that matches the machine sitting on your bench. You pick the filament that is loaded in the AMS or on the spool holder. You click slice and you preview the tool path. Bamboo Studio is excellent at slicing and at managing your printer.

It is not a CAD tool and trying to use it as one is a frustrating dead end. The point of the CLI we just designed is to make the CAD step happen somewhere else in Python on your terms and to hand Bamboo Studio exactly the kind of file it wants to consume. The integration is therefore beautifully boring. The CLI writes STL into a known folder. Bamboo Studio reads from that folder.

There is no plug-in, no API call, no special configuration. Boring is what you want at this layer. One of the most underrated features of doing CAD in code is that you know more about the part than you would if you had drawn it by hand, and you can write that knowledge down. When the verb generates the phone stand, it knows exactly which face is the back, exactly where the cable cutout is and exactly which edges are going to overhang. So the CLI can include all of that as structured hints in the parts manifest.

The recommended orientation, which face to put down on the build plate. The predicted support locations so you know where the print will need a little scaffolding to keep from drooping. The minimum wall thickness so you can pick a layer height that flatters it. An infill suggestion because a desk stand needs less infill than a loadbearing bracket. And a rough print time estimate which is enough to tell you whether to start the print before or after lunch.

The really nice payoff is that the AI front end can read this manifest. Notice that a part is going to need a lot of supports and on its own propose a different design that prints cleaner. That feedback loop design intent meeting print reality is something you cannot easily build into a graphical CAD tool. It comes for free when the design is text. I want to be careful here because the CAD query community can be a little evangelical and I do not want anyone to leave this video thinking parametric is always the right answer.

It is not. Parametric code is unambiguously the right tool when the part is functional and the dimensions matter. brackets, jigs, fixtures, organizers, mount knobs, enclosures, anything where someone is going to ask whether it's fits a specific screw, a specific phone, a specific shelf. Parametric is also the right tool when you need variance. A single CAD query script can produce 20 sizes of the same bracket by looping over a dimension list, which is the kind of thing that takes hours in a graphical tool.

Where parametric loses and loses hard is on organic shapes, a figurine, a piece of jewelry, an anatomical model, a sculpted decorative panel. Those parts live in mesh editing tools like Blender or ZBrush and trying to coax them out of CAD query is fighting the kernel. The honest answer is that you pick the tool based on what the part is, not based on which tool you happen to like. The AI workflow we are talking about today is specifically aimed at the functional half of the world. After enough printed parts, you develop a feel for which shapes the AI plus CAD query workflow handles well and which ones it fights.

And I want to share the rough shape of that map so you can pick your first project intelligently. The sweet spot is small functional parts whose dimensions you can describe in a sentence. A wall hook sized for one specific cable. A drawer divider that fits one specific drawer. a clip to route a USB cable under your desk.

These are jobs that would take 20 to 90 minutes by hand. And the workflow we just designed turns them into less than a minute of design plus a few hours of printing. The next tier up is enclosures, lids, knobs, and small mechanical assemblies. These work, but they take a few iterations and benefit from a human who knows which filt matters. The harder territory is assemblies with many mating parts, especially anything involving threaded inserts, snap fits, or precision fits between printed pieces.

The CLI can help, but you will be in the loop more. The genuinely painful territory where the workflow does not really apply is lattises, generative organic forms, and free form surfaces. Different tools, different talk. Every honest talk about an AI workflow needs a slide about where the workflow falls down. Because if you only hear the cheerful parts, you will trust the system more than it do deserves and burn a kilogram of filaments.

The deepest limitation is that the model still cannot see the part it just designed. A manifold STL that passes every numeric check can still be ugly, can still be fragile in unexpected directions, and can still be impossible to actually assemble with the other pieces in your project. A bracket that bolts a shelf to a wall might be perfectly correct in CAD and yet require a screwdriver that does not fit between the wall and the bracket. The CLI cannot catch that. The second limitation is prompt drift.

Over a long conversation, the model will quietly redefine what it thinks you ask for and the parts manifest is genuinely your only defense because it is the one place where the actual numbers are recorded in plain sight. The third limitation is that a human still owns the decision to print. The CLI can hand you a beautiful STL, but the choice of whether to commit 2 hours of printer time and 40 g of plastic is yours. Build the workflow. Trust it for what it is good at.

Keep your hand on the slicer. Step back for a moment and look at the full pipeline as one picture because this is where the shape of the future starts to become visible. You sit down with an idea. The idea lives in your head as plain English. the way ideas always have.

You hand the English to an AI assistant, which turns it into a call to the CLI we designed. The CLI turns the call into a CAD query script, runs the script, validates the result, and writes an STL. You drop the STL into Bamboo Studio, which slices it, and sends G-code to your printer. A few hours later, you walk over to the printer and pull a real physical object off the bed. The whole pipeline from idea in your head to part in your hand used to require either expensive engineers or a real personal investment in CAD skills.

The new pipeline still requires good taste and good ideas, but it does not require the years of mouse practice that used to gate the front door. That is what is genuinely new about this moment. The bottleneck has moved upstream. The new question is not whether you know solid works. It is whether you have the idea worth printing.

If you have made it this far and you want a concrete next step, here is the project I would recommend for your first weekend with this workflow. Pick one annoying gap in your home. A hook for a cable that keeps falling off your desk. A bracket for a router that lives behind your TV. a clip for that thing in the kitchen drawer.

Anything small, functional, and specific to your space. Saturday morning, install CAD query with pip and write a single Python file with one verb that builds the rough shape of the thing you need. Saturday afternoon, generate a first version, slice it in Bamboo Studio, and print it. The first one will be wrong in two or three small ways, and that is the point. Saturday evening, write down what is wrong.

Sunday morning, ask your AI assistant to adjust the parameters based on your notes. Sunday afternoon, print version two, install it, and take a photo. By Sunday evening, you will have a working part on your wall, a small CLI of one or two verbs you wrote yourself, and a real feeling for how the loop works. That feeling is the entire prerequisite for doing more interesting things later. If you compress this whole video down to a single card you could tape next to your printer, this is what would be on it.

CAD as code is what makes CAD AI friendly. The model needs the part to be a script and CAD query is the cleanest way to get there today. Wrap that script behind a small CLI of safe verbs. Never let the model write raw selectors or raw boolean operations because that is where the failures live. Invest in validation.

Bounding box, manifold, wall thickness over those four checks are what turn a generated STL from a guess into a part you can trust. Let Bamboo Studio be a slicer because that is what it is excellent at. Threw your design somewhere else in Python in a place where the AI can help. And finally, the bottleneck of the whole pipeline has moved upstream. The new constraint on what gets made is not whether you can drive fusion.