Zoo.dev text-to-CAD: a working review

I first tried Zoo.dev on a Tuesday afternoon when I had a sensor bracket to mock up and exactly zero motivation to sketch it from scratch. I typed "rectangular bracket, 60mm by 35mm, 3mm thick, two M4 clearance holes 20mm apart, 10mm from the right edge" into the text-to-CAD prompt box, waited about twelve seconds, and got back a solid body. Not a mesh. Not a render concept. A STEP file I could open in Fusion 360, select faces on, and measure. The hole diameter was 4.3mm, which is correct for M4 clearance. The overall dimensions were within a tenth of what I asked for. I sat there feeling the specific mix of impressed and suspicious that comes from watching a tool do something surprisingly well for the first time.

Then I tried a more complicated part, and the feeling shifted. But we'll get there.

What Zoo.dev actually is#

Zoo.dev, formerly known as KittyCAD, is an API-first text-to-CAD platform built on a custom GPU-native geometric kernel the team wrote themselves. That last part matters. Most AI 3D tools bolt a language model onto existing mesh-generation pipelines and call it a day. Zoo built their own B-Rep kernel from scratch, designed to run on GPUs, designed to produce the kind of solid geometry that engineers actually use.

The product has two faces. There's the web-based Design Studio where you type prompts and get models, and there's the API (with a Python SDK called kittycad) that lets you integrate text-to-CAD into your own pipeline. Both produce the same output. For the full concept and how Zoo compares to other approaches, I covered that in the text-to-CAD guide.

The interface and workflow#

Zoo's Design Studio is deliberately minimal. A text box. A 3D viewport. Some format export buttons. That's essentially it.

You type a prompt, wait somewhere between ten and thirty seconds, and get a 3D model in the viewport. You can rotate, zoom, and inspect the geometry. If you like it, you export. If you don't, you rephrase and try again. There's no feature tree, no timeline, no sketch environment. It's a generation tool, not a modeling environment.

This is both the strength and the limitation. Anyone who can describe a part in English can try it. But you can't tweak the output inside Zoo itself. Whatever comes back, you either accept it or re-prompt. If you need to move a hole by 3mm or add a chamfer the AI forgot, you're exporting to Fusion 360 or SolidWorks and doing it there.

I've settled into a workflow where I generate in Zoo, export as STEP, import into Fusion, and fix whatever needs fixing. For simple parts, the fix list is short. For anything moderately complex, the fix list is the whole part. The Zoo text-to-CAD tutorial walks through this workflow step by step.

What it handles well#

Simple mechanical parts. That's the honest answer, and it's not as dismissive as it sounds. A lot of real engineering work involves simple mechanical parts, and generating them from text instead of sketching them from scratch does save time.

Brackets, mounting plates, standoffs, basic enclosures, spacers, adapter plates with bolt patterns. These are Zoo's sweet spot. If you can describe the part in two or three sentences with specific dimensions, you have a reasonable shot at getting usable geometry back. I've had good results with prompts like "L-bracket, 3mm thick, 50mm legs, four M5 clearance holes on a 30mm square pattern on the base" or "rectangular enclosure 100mm by 60mm by 40mm, 2mm wall thickness, open top, four M3 mounting bosses in the corners."

The geometry comes back as proper B-Rep. Faces are selectable. Edges are real edges, not mesh approximations. The STEP files open cleanly in every CAD tool I've tested.

The trick is learning to write prompts that leave the AI as little room as possible to improvise. Vague prompts produce vague parts. I went into this more in text-to-CAD prompt engineering, but the short version is: treat the prompt like you're dimensioning a drawing, not describing it to a friend.

What it doesn't handle well#

Anything where the relationships between features matter more than the features themselves.

I asked Zoo for a spur gear once. 20 teeth, module 1.5, 8mm bore. What came back had roughly the right number of teeth and roughly the right outer diameter, but the tooth profile was cosmetic. An involute curve has a specific mathematical shape that determines how gears mesh. Zoo's teeth looked gear-shaped but weren't involute by any useful definition. For a render, acceptable. For a gear that needs to mesh with another gear, useless.

Assemblies are out of reach. Zoo generates single bodies. If you need a hinge with a pin, a box with a lid, or two mating parts with clearance fits, you're generating each piece separately and hoping they work together, which they usually don't without manual adjustment.

Sheet metal parts don't work because Zoo doesn't understand bend allowances, K-factors, or flat patterns. You get a shape that looks like folded metal but can't be unfolded because it was never modeled as sheet metal in the first place.

Complex surfacing, organic shapes, lofted features, swept profiles along 3D paths: all either absent or unreliable. The kernel is built for prismatic geometry, and it shows.

Draft angles for molding, thread callouts, GD&T: none of that exists in the output. The tool produces geometry, not manufacturing intent.

Output quality and accuracy#

The results are inconsistent enough that any single example is misleading.

On my best tests, dimensions came back within 0.1mm of what I asked for. On my worst, I got a part where the overall width was off by about 8%, which on a 120mm part is nearly 10mm. Not a rounding error. A genuine miss.

The pattern I've noticed: simpler geometry with very explicit dimensions comes back more accurately. Add more features, more relationships between them, and the accuracy degrades. Ask for "four holes equally spaced" and you might get four holes that are almost equally spaced but not quite.

I always measure critical features after importing the STEP file. Always. The output is a starting point, not a finished part. If you treat it as a rough draft that needs checking, you'll be fine. If you treat it as production-ready geometry, you'll have a bad day eventually.

File formats#

Zoo outputs STEP, glTF, GLB, OBJ, STL, PLY, and FBX. The one that matters for engineering is STEP.

A STEP file from Zoo opens in Fusion 360, SolidWorks, Creo, NX, and FreeCAD as real solid geometry. Selectable faces. Measurable edges. You can add fillets, cut pockets, and apply chamfers like it was native geometry. A lot of "AI 3D tools" output OBJ or STL and call it CAD, which is like calling a photograph of a blueprint a technical drawing. Zoo's STEP output is the cleanest I've seen from any dedicated text-to-CAD tool.

The API#

This is where Zoo gets interesting for anyone who builds things beyond individual parts.

The Python SDK (kittycad) lets you send text prompts programmatically and get geometry back. You can batch-generate parts, build custom interfaces on top of Zoo's engine, or integrate text-to-CAD into a product pipeline.

I've used the API to generate fifteen bracket variations from a script, each with slightly different dimensions, exported as STEP files for comparison. Twenty minutes to write the script, five minutes to generate all the variants. Doing that by hand in Fusion would have been an hour of sketch-modify-export tedium.

The API documentation is good. Not perfect, but better than most developer docs I've dealt with from CAD-adjacent companies. The Zoo text-to-CAD API tutorial covers the setup and a few practical examples.

The KittyCAD kernel#

Zoo's kernel deserves its own mention because it's the thing that makes their output different from tools that generate meshes and hope nobody notices.

The KittyCAD kernel is a GPU-native B-Rep geometric kernel. Most of the industry runs on Parasolid (Siemens) or ACIS (Dassault). Building a new kernel from scratch is a massive undertaking and a bold bet. The advantage is that it was designed for this exact use case without decades of legacy baggage. The downside is that it's newer and less battle-tested than Parasolid, which has been handling B-Rep operations since the 1980s. I've hit a few cases where fillets don't fully resolve or internal geometry appears that shouldn't exist. These are kernel-maturity issues, and they're real today even if they'll improve over time.

Pricing#

Zoo has a free tier that's generous enough for actual testing. You get a limited number of API calls per month, but enough to evaluate the tool properly before deciding whether it's worth paying for. The paid tiers add more API calls and higher priority.

I won't quote exact prices because they've changed before and they'll change again. Check zoo.dev for current numbers. The free tier is the right place to start.

Where it fits in a real workflow#

Zoo is a first-draft generator. It's not a replacement for CAD software. It's the thing that gets you from a blank screen to a rough solid in thirty seconds instead of ten minutes.

My workflow: generate in Zoo, export STEP, import into Fusion 360, measure everything, fix what's off, add missing details, constrain for future edits. On simple parts, Zoo saves me five to fifteen minutes. On anything complex, it saves nothing because I rebuild from scratch anyway.

Where Zoo adds the most value is iteration speed. "What if the bracket was 10mm wider? What if the holes were on a different pattern?" Each variation takes thirty seconds instead of modifying a sketch and hoping the feature tree survives.

The verdict#

Zoo.dev is the most serious dedicated text-to-CAD tool available right now. The custom kernel produces real B-Rep geometry. The STEP output is usable in professional CAD software. The API is well-documented and the free tier is honest. For simple mechanical parts with specific dimensions, it works. If you want to see how it stacks up against the rest of the field, the best text-to-CAD tools comparison covers that.

It's also limited in exactly the ways you'd expect. Complex geometry breaks down. Assemblies don't exist. Manufacturing intent is absent. Accuracy requires verification on every output. The kernel is young and occasionally produces artifacts that a mature solver wouldn't.

If you're a professional engineer, Zoo won't replace your CAD skills. It might save you a few minutes on simple parts and real time on variant generation. If you're someone who needs occasional mechanical parts but doesn't live in CAD software, Zoo is probably the best option that exists today.

I keep coming back to it, which is the most honest endorsement I can give a tool. Not because it's perfect. Because it's useful just often enough that closing the browser tab feels premature. In a space full of demos that promise everything, a tool that delivers something specific and real is worth paying attention to.