CADAGEN vs. Zoo.dev: Which Fits Your Workflow?
An honest, feature-by-feature comparison of CADAGEN and Zoo.dev's Zookeeper for text-to-CAD generation — what each is actually built for, and where each one's approach is genuinely stronger.
CADAGEN and Zoo.dev solve overlapping but not identical problems: Zoo.dev, through its Zookeeper conversational CAD agent, is built as a developer-facing, API-first, general-purpose text-to-CAD platform with its own parametric scripting language (KCL); CADAGEN is built around a standard-part catalog for common mechanical components plus a human-engineer fallback for custom or uncertain results. Neither claim is a knock on the other — they reflect different bets about where reliability should come from.
What Zoo.dev / Zookeeper actually is
Zoo's Zookeeper is a conversational CAD agent, shipped as part of Zoo Design Studio (v1.1, January 2026). It generates parametric models expressed in Zoo's own scripting language, KCL, and its Text-to-CAD API returns STEP and glTF files by default, with STL also supported. Zoo also offers a capability to import existing STEP/STL files and have Zookeeper attempt to reconstruct them into editable, parametric KCL programs — useful if you're starting from a scanned or legacy file rather than a text description.
What this is genuinely good for: developers building on top of a CAD API, teams that want a scriptable, parametric modeling workflow they can version and automate, and users comfortable working in a code-adjacent modeling language rather than a purely conversational interface.
What CADAGEN is built around
CADAGEN turns a written or visual description of a mechanical part — standard or custom — into a CAD (STEP) file, with two design choices that shape how it behaves differently from a general freeform generator:
- Standard components (fasteners, bearings, gears) are pulled from real catalog geometry, not freely generated — see generating fasteners, gears & bearings correctly for why this matters for parts that have to match an actual purchasable component.
- When automation isn't confident in a custom or complex result, the job routes to a human engineer rather than shipping a plausible-looking file with an unclear reliability level — see when to trust automation vs. ask an expert.
What this is genuinely good for: users who need standard mechanical components specified correctly with minimal risk of a near-miss dimension, and situations where "I'm not sure this is right" should trigger a human review rather than a confident-looking but unverified output.
Side-by-side
| CADAGEN | Zoo.dev / Zookeeper | |
|---|---|---|
| Primary interface | Text or image description | Conversational agent + KCL scripting |
| Output formats | STEP (native focus) | STEP and glTF by default, STL supported |
| Standard parts (bolts, bearings, gears) | Pulled from real catalog geometry | Freeform generation, general-purpose |
| Complex/uncertain results | Routed to a human engineer | Iteratively refined via conversation with the agent |
| Best fit | Standard-part-heavy mechanical design, users who want a manufacturability safety net | Developers wanting an API-first, scriptable, parametric CAD workflow |
| Import existing files for editing | Not the primary workflow | Yes — reconstructs STEP/STL into editable KCL |
Where Zoo's approach is genuinely stronger
To be direct about it: if your workflow is developer-centric — you want to call an API, script parametric variations, version your models like code, or import and re-parametrize an existing STEP file — Zoo's KCL-based, API-first approach is purpose-built for that in a way a conversational-only tool isn't. Their ability to reconstruct existing geometry into an editable, parametric program is also a genuinely distinct capability that addresses a real, common problem (inheriting a mesh or STEP file with no editable history).
Where CADAGEN's approach is genuinely stronger
If your work involves specifying real mechanical hardware — fasteners, bearings, gears — accuracy against an actual catalog part number matters more than generative flexibility; a bolt that's "approximately M10x1.5" isn't useful if it doesn't match a real tap. And if you'd rather have an uncertain or complex result escalated to a person than receive a confident-looking file with an unclear reliability level, that's a deliberate design choice in how CADAGEN handles the parts of a job that automation can't confidently finish.
A question worth asking either tool directly
Regardless of which platform you're evaluating, it's worth asking the vendor directly: "when a generated bolt, bearing, or gear is specified, does it come from real catalog geometry, or is it generated freeform each time?" The answer changes how much independent verification you need to do before trusting a standard-hardware callout. It's also worth asking: "what happens when the system isn't confident in a result?" — a silent, confident-looking output and an explicit "this needs review" flag are very different experiences once you're relying on the output for something that will actually be manufactured.
Where the two approaches could complement each other
In practice, a developer-heavy team might use an API-first, scriptable platform like Zoo for custom, novel geometry and version-controlled parametric workflows, while still wanting a manufacturability safety net specifically for the standard hardware embedded in those designs — the bolts, bearings, and gears that need to match a real catalog part rather than an approximated shape. These aren't mutually exclusive tools serving the same job; they're addressing different parts of a design workflow, and recognizing that is more useful than treating the comparison as a single winner-take-all decision.
The honest takeaway
These aren't really competing on the same axis. Zoo is betting on making a general-purpose, scriptable CAD agent as capable and developer-friendly as possible. CADAGEN is betting on being right about the parts of a design where "right" is verifiable (standard components) and honest about the parts where it isn't (complex custom geometry, handed to a human). If your priority is API-first scriptable modeling and importing/reconstructing existing files, look at Zoo. If your priority is a manufacturability safety net around standard mechanical parts with a human fallback for the rest, that's the case CADAGEN is built for.
Sources: Zoo.dev — Zookeeper research page · Zoo.dev — Text-to-CAD API docs · Zoo.dev — FAQ. Pricing and feature details change — check zoo.dev directly for current terms before deciding.