OPEN SOURCE DEEP DIVE
Text-to-CAD: the open-source plugin and skill suite that gives coding agents CAD superpowers
text-to-cad turns parametric CAD into a local agent skill: plain language or an image becomes a STEP model with STL/3MF/GLB exports, plus DFM review, dimensioned drawings, URDF/SRDF/SDF robot descriptions and 3D printing, sheet metal and CNC integrations. Kernel is build123d on OCP; the shape is twelve skills plus the cadgen engine and a local CAD Viewer. MIT, about 20.6k stars.
What it is
text-to-cad is a CAD plugin and skill suite you install into a coding agent. It gives Claude Code, Codex, Cursor, Gemini and Grok a local workflow that turns plain language or a reference image into parametric CAD models, with STEP as the primary artifact and STL, 3MF and GLB as exports. It also runs design-for-manufacturing checks, produces dimensioned engineering drawings, and connects to 3D printing, sheet metal and CNC fabrication services. The repository went open source in April 2026 under MIT and had gathered roughly 20.6k stars and 2k forks by October 2026; the kernel is build123d on OpenCascade's Python binding OCP, shipped as the cadgen package on PyPI at version 0.7.21, with docs at texttocad.dev.
The repository has three faces. skills/ is the product: twelve skills covering modeling, off-the-shelf part search, drawings, manufacturing review, robot description files and print dispatch. packages/cadgen is the published engine and command surface. models/ is a maintained corpus of fixtures, from planetary gear stages and six-axis industrial arms to a research humanoid and a tendon-driven hand. The root is also the plugin package: .claude-plugin, .codex-plugin, .cursor-plugin, gemini-extension.json and mcp.json all live there, and the latest branch that installers follow carries the plugin alone, one commit per release.
Twelve skills, from modeling to the shop floor
| Skill | What it does |
|---|---|
| CAD | Creates and edits parametric models from language or images; STEP first, with STL, 3MF and GLB exports |
| step.parts | Finds off-the-shelf STEP parts: screws, bearings, motors, connectors |
| Engineering Drawing | Dimensioned drawing PDFs from a part: views, hidden lines, dimensions, hole callouts, title block |
| DXF | 2D DXF drawings from Python sources or CAD geometry: profiles, templates, gaskets, cut layouts |
| URDF | Robot structure files: links, joints, limits, inertials, meshes |
| SRDF | MoveIt planning groups, end effectors, poses and collision rules on top of a URDF |
| SDF | Simulator models and worlds with frames, physics, sensors and lights |
| SendCutSend | Checks DXF and STEP files before upload to SendCutSend |
| DfAM Check | Mesh printability per process: wall thickness, overhangs, support volume, build orientation |
| DFM | Sheet metal, CNC and injection molding review; every finding carries measured evidence and a cited rule |
| G-code | Slices models into printer-ready G-code with OrcaSlicer and the user's own presets |
| Bambu Labs | Sends prints through Bambu Connect, the official app or Bambu Studio |
The division of labor draws one clean line: the CAD skill owns every 3D part while the DXF skill owns its 2D projection; robot structure belongs to the URDF, SRDF and SDF skills; the manufacturing side (DFM and DfAM) only issues findings backed by measured evidence and a cited rule, never touching geometry; G-code and Bambu Labs carry the model into a real printer.
Runtime model: one launch command, one warm build daemon
Every door shares a single uvx launch command (uvx --no-config --managed-python --python 3.13 --from cadgen==0.7.21 plus the subcommand), so the plugin's MCP server, every agent thread and every skill command point at one installation and therefore share one warm build daemon and its build pool. A model is plain Python: a parameterless function decorated with @step, @dxf, @stl, @glb, @threemf or @eng_drawing that returns a build123d shape. python model.py is the only source door: it gates, builds and writes every output the decorators declare. The CLIs take documents only: cadgen step build, cadgen snapshot and friends accept saved STEP or STL files and, when a tree is missing, compile it from those bytes in the build pool, never from a script.
Nineteen design laws: keeping plausible-wrong out
packages/cadgen/README.md writes the architecture as nineteen laws, each with a pressure test to apply before coding. The hardest ones: generated files are totally independent of their source, so deleting every .py in a project changes nothing a renderer shows, because the sidecar's kinematics are resolved numbers and labels; the store (~/.cache/cadgen) contains only derived results, content-addressed, capped at 20 GB by default, deletable and rebuildable at any time; byte determinism is the writers' promise, not the kernel's, so two runs may differ in a last digit, equal bytes only mean reuse, and two builds are compared by geometry within a tolerance, never by file hash; decorator inputs never change the geometry, they only decide where files land, how they are written and what the sidecar declares, and two features that violated this (the kinematics bake point and the part/assembly kind flag) were deleted; caches sit around a model run, never inside it, so a script answers every equality check identically inside cadgen and under plain Python; and once installed, no command, build, snapshot, server or page waits on the network.
Law ten is the moral floor of the document: loud failure or correct output, nothing between. Exiting 0 with plausible-wrong bytes is named the cardinal sin; there are no silent fallbacks and no glob guessing, and a failed render leaves no file at the requested path.
Seeing the model: the CAD Viewer and two MCP Apps host shapes
cadgen viewer is a local HTTP server (port 3245 by default) that serves any CAD file on the machine by absolute path. cadgen mcp is an MCP Apps server, and hosts are told apart at initialize: a host that declares tab entrypoints (Codex) gets a sidebar home, one CAD tab per thread and Open with CAD; every other MCP Apps host (Claude Desktop) mounts inline cards in the chat, where a newer card retires the older ones to a still of their last frame. Each view keeps its own history with browser semantics for back and forward; the agent can read views, screenshot them, and take back what the person selected.
The robotics side: URDF, SRDF, SDF and committed fixtures
For the embodied-AI community the interface is three robot-description skills: URDF writes links, joints, limits, inertials and meshes; SRDF adds MoveIt planning groups, end effectors, poses and collision rules; SDF builds simulator models and worlds with frames, physics, sensors and lights. The fixtures in models/ are not toys: the research humanoid ships left and right hands as separate scripts over a shared library, and the corpus includes a tendon-driven hand, a six-axis industrial arm, a lunar rover corner assembly and a reconstruction of Falcon Heavy from public sources. Every cad project has the same shape, authored code in src/ and artifacts in format folders, all generated output gitignored so a fresh clone regenerates by running the scripts.
Manufacturing and dispatch: findings must carry evidence
The DFM skill reviews a part for sheet metal, CNC machining or injection molding, and every finding carries measured evidence plus the rule it cites, measuring draft, undercuts and projected area from a mesh. DfAM Check measures mesh printability per process: wall thickness, overhangs, support volume and build orientation. The SendCutSend skill checks DXF and STEP files before upload; the G-code skill slices with OrcaSlicer using the user's own printer presets; the Bambu Labs skill sends prints through Bambu Connect, the official app or Bambu Studio. The engineering drawing skill turns a part into a PDF with views, hidden lines, dimensions, hole callouts and a title block.
Engineering governance: merging a release PR is the release
A pull request that changes VERSION is a release, and merging it releases: the Publish Release workflow finds the Test run that recorded the merged tree as tested in full, builds the plugin ZIP, the bundle and the wheel, installs and exercises the wheel, uploads source maps and the wheel to PyPI, waits until PyPI's index lists it, and only then commits the plugin alone onto the latest and claude-plugin branches before deploying the docs site and tagging. The test surface runs to hundreds of files under tests/python, covering the store, the daemon, STEP read-back, snapshots and viewer routes, plus a golden snapshot suite for the viewer. Telemetry is on by default but sends only counts and failure reasons from a fixed vocabulary, never file names, paths, contents or prompts, and uvx cadgen telemetry off turns it off and deletes what was sent.
Boundaries and honesty
It is not cloud CAD and it is not mesh extraction: the artifact is a parametric model as code, diffable, reviewable and version-controllable, plus its STEP document. The OCP wheel is unsigned, so Windows 11 Smart App Control blocks it; the repository documents that pitfall and the WSL workaround instead of pretending compatibility. For an agent, the value is turning "design a part" from GUI manipulation into a code run that can be reviewed, retried and put in CI, exactly the shape robot structures, fixtures and end effectors need.