Zoo Text-to-CAD in Practice 2026: From Prompt to Design Asset

Zoo Text-to-CAD generates editable, parametric CAD models from natural-language prompts: concretely, a STEP file and optionally KCL code per call. The concept, and why functional parts need B-Rep generation rather than mesh generation, is covered in our Text-to-CAD guide. This article is the hands-on sequel.

There is a real gap between “generated something once, neat” and “use it as a design tool every week.” How do you budget the free tier, when do you stop prompting and start feature-editing, how do you turn KCL code into a reusable asset, and how do you automate the parts you make repeatedly? Closing that gap is the subject here. Tool-agnostic selection criteria live in the AI CAD copilot comparison; this piece commits to using one tool deeply.

What Changes at the Start of a Prototype

In the traditional flow, the first gate is transcribing the part in your head into CAD: pick a sketch plane, add constraints, extrude. None of it is hard, but starting from zero has a psychological cost. Zoo Text-to-CAD delegates that first 80 percent to language and shifts the human job to the final 20 percent of finishing.

What matters is that the output arrives in a format that can survive finishing. Every call yields a STEP file, with KCL code alongside. Generated models are editable in the standard sketch-and-feature-tree workflow, so the division of labor between AI drafts and human fixes never breaks down. There is no dead end at the repair stage, unlike mesh generators.

That changes how you iterate. There is no need to chase a perfect first prompt; secure a roughly-right shape in tens of seconds, then drive dimensions home with CAD operations. Same number of design iterations, visibly less time per lap. Know the tool’s lane before you start: it excels at parts whose dimensions can be stated in words, like flanges, brackets, shafts, and fixtures. Organic sculpting is out of scope, and knowing that up front prevents most disappointment.

Setup and What the Free Tier Actually Contains

Two ways in. The quick one is the browser build at app.zoo.dev, no install required, officially positioned as a trial environment. Once you decide to keep using it, move to the desktop Zoo Design Studio for Mac, Windows, or Linux; the same account works for both.

The free tier is worth understanding in detail. The Free plan includes all core CAD workflows, 20 minutes of Zookeeper reasoning per month, and developer API usage worth 10 dollars per month (July 2026, per the official FAQ). In other words, using it purely as CAD is broadly free; costs only kick in when you lean hard on generation and reasoning. Upper-tier prices move around, so confirm on the official pricing page.

If you plan to touch the API, create an API token from your account now. Auth is a standard Bearer token in the Authorization header; issuing a token is free, so having one ready makes the automation section later feel lighter. One environmental note: the geometry engine runs in the cloud, so there is no offline use. That is the flip side of not caring about local GPU power.

The Core Loop: Prompt, Generate, Measure, Edit

Practice reduces to running one four-step loop fast. First, order the part: the pattern is part name plus governing dimensions plus feature quantities, and Zoo’s own example “Engine valve, 120 mm long, 30 mm head, 6 mm stem” is a ready-made template. Prompt details are covered in the prompt section of the Text-to-CAD guide.

Second, once it generates, measure before you admire. Check the governing dimensions you intended: outer diameter, overall length, hole positions. Because Zoo output is parametric, measuring is not pass-or-fail; it is building a list of what to fix. Third, choose the repair route. If the overall structure is wrong, rewriting the prompt and regenerating is faster. If the structure is right and a few dimensions are off, switch to feature editing. Getting quick at this call is what proficiency with the tool means.

Make the measuring checklist concrete: first the diameters and widths that participate in fits, since the part fails as a part if these drift; second, hole pitch and position; third, overall envelope. If you print, fold in material and layer-induced dimensional shifts at the end as CAD-side tolerance tweaks; that is a manufacturing problem, not a generation problem, and separating the two speeds up diagnosis.

Typical failure patterns: prompts contaminated with vague adjectives, and one-shot orders for complex multi-part assemblies. Fix the former with explicit numbers and quantities, the latter by splitting into per-part orders and assembling in CAD. Give the tool work at the granularity it is good at, exactly as you would with a human team. When a lap is done, export STEP; for printing, convert to STL in CAD and hand it to the slicer.

Finishing in the Feature Tree

A generated model comes with its operation history as a feature tree, and finishing means reading that tree and retyping only the values that need it. Zoo states that mechanical engineers never have to touch KCL: point-and-click covers sketching, extruding, and assembly, while every GUI edit keeps being recorded as KCL behind the scenes. Two audiences, one data model.

Editing has a canonical order. Fix constraint dimensions tied to function first: mating diameters, hole pitch, mounting-face distances. Then adjustments for printing or machining: wall thickness, fillets, draft. Cosmetics last. Follow the order and you rarely get late edits invalidating earlier ones. A finished model at this stage is no longer “something the AI made”; it is design data with dimensional justification. Generation is only initial velocity, and the value lands during feature-tree finishing.

KCL as a Design Asset

KCL, the KittyCAD Language, is Zoo’s purpose-built language for describing CAD geometry. The official docs frame it as a language for designing real-world engineering objects rather than software: units-aware numbers, sketches, and feature chains sit at the center of the language instead of programmer trivia.

The practical payoff of owning designs as code is reuse and diffing. Clean up the KCL for a fixture you make often, and variants become variable edits. Under Git, “what changed since last week” is a line-level diff, and design review can borrow code-review habits. Compare that with emailing binary CAD files back and forth. The standout language feature is built-in units on numeric types. In a general-purpose language, whether 40 means millimeters or inches lives in comments and naming conventions, and unit mix-ups are a classic engineering-software accident. Making units a language feature is the right call for physical design, and it makes reading code feel closer to reading a drawing.

Learn from official resources: the KCL Book covers functions, arrays, modules, and unit-typed numbers systematically, with the standard-library reference in the official docs. We deliberately show no syntax here because the language is under active development; treat the latest official text as ground truth. Note that the once-popular GitHub samples repository (KittyCAD kcl-samples) was archived on April 21, 2026 and is read-only; samples now live in the official Aquarium. If an older article points you at the repo, start from Aquarium instead.

Learning from Official Samples

Modifying working samples beats writing from scratch. The collection passed 40 samples at the time the old repo was archived and has grown to roughly 150 in Aquarium, with a usefully wide spread: Gridfinity bins and baseplates, cycloidal gears, ball bearings, hex nuts, socket-head cap screws, pipe-flange and wheel assemblies, even LEGO-compatible bricks and a French press.

Use samples in three stages. Read: generate as-is and cross-reference the feature tree against the KCL to feel which operation maps to which code. Modify: rewrite only dimension variables, say resizing a Gridfinity bin to your drawer. Quote: lift proven structures like a bearing seat or a bolt-hole pattern into your own designs. A verified parametric part beats re-ordering from scratch every time, in both speed and reliability. The endpoint of the path is being able to pick among prompt generation, GUI editing, and KCL editing per part. At that point Zoo Text-to-CAD is standard equipment, not a demo.

Zookeeper in Practice

Zookeeper, the conversational CAD agent, has four jobs: generate from text, edit existing models through dialogue, answer design questions, and compute physical properties like surface area, volume, mass, and center of gravity. The free 20 minutes of monthly reasoning lasts longer when you decide where to spend it.

As a rule of thumb, simple fresh generations are cheap since one prompt suffices. Conversational editing pays off most: stacking requests like “two more of these holes” and “walls to 3 mm” saves real time while you are still slow in the GUI. Once GUI skills catch up, invert the split: do simple dimension edits yourself and reserve the agent for edits that restructure geometry. Property calculations are quietly powerful, turning material-cost estimates and tip-over sanity checks into questions you ask without leaving CAD.

Keep the boundary explicit: Zookeeper output is still generative-AI output. Final dimensions and strength judgments on functional parts go through human verification, and for anything safety-adjacent, load-bearing brackets or fixtures near heat, treat computed properties as reference values and keep the old-fashioned habit of physical tests. Faster analysis should thicken verification, not excuse thinning it.

Automating with the API

Recurring generations graduate to the API. Zoo’s API exposes an ML section for machine-learning CAD generation, the KittyCAD engine API for manipulating 3D files, and file-conversion endpoints for create, fetch, and list. Auth is the Bearer token from your account page, nothing exotic; see the official docs.

The classic win is part families: mounting plates whose hole positions differ per customer, fixtures with a size run. Instead of a human retyping prompts, a script walks a parameter table and queues generations. The 10-dollar monthly API allowance is exactly the right size to pilot that idea. File-conversion endpoints are worth remembering too: the standard output is STEP plus KCL, and when a downstream process demands another format, the conversion API bridges it, though it sits on the paid side of the meter.

Operationally, design around exhausting the free allowance: experiment early in the month, and only convert to paid once a pattern demonstrably works. At that point Zoo Text-to-CAD stops being a chat window and becomes a pipeline component; because designs are code (KCL) and API-addressable, CI-style thinking, generate, verify, archive, ports into CAD.

Summary: From One-Off Generation to Design Assets

Running Zoo Text-to-CAD well is the process of converting one-shot novelty into everyday design capability. Start in the browser, graduate to desktop. The free tier is 20 minutes of Zookeeper reasoning plus 10 dollars of API monthly, with core CAD features free. The loop is order by prompt, measure, choose regenerate-or-edit, export STEP. Finish constraint dimensions first, then manufacturing tweaks, then looks. KCL turns designs into diffable, reusable assets; learn from the KCL Book and the roughly 150 samples in Aquarium (the GitHub repo was archived 2026-04-21). Spend Zookeeper minutes on conversational edits and property checks, keep final judgment human, and scale repeat work through the Bearer-token API within the 10-dollar allowance.

As a next step, pick one thing you keep remaking in different sizes and run it through prompt, finish, and KCL save. When the second generation comes out dramatically faster than the first, “design asset” stops being a phrase. For where this tool sits among its neighbors, see the AI CAD copilot comparison and the AI 3D design complete guide.

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.