Your CAD caddie. Text to CAD. Describe a part — CADDIE writes parametric Python, the runner emits STEP / STL / GLB / 3MF / DXF, a kernel-truth DFM lint runs on every export, and an in-browser viewer reloads on save.
Wire CADDIE into the user's AI coding agent in one step. From there, the operator describes a part in plain language and CADDIE emits parametric Python against an industrial-grade geometry kernel; the local runner exports five file formats from the same source on every run. The geometry is parametric, not a one-off mesh — change a dimension and re-run; the part regenerates cleanly. Source code, exports, and DFM reports stay locally with the operator — version-controlled, diffable, editable by hand or by agent. Runs locally; no cloud round-trip required. Hardware IP stays under the user's own source control, not in a third-party generation service.
Ask any modern coding agent to design a bracket. You will get a marketing image, a paragraph of advice, or — at best — an unreliable mesh approximation that cannot be edited or manufactured. None of those are a part. A part has named dimensions, a kernel-true representation, a manufacturable geometry, and an audit trail that another engineer can read and edit. CADDIE is the smallest possible bridge between agent reasoning and real CAD: the agent writes parametric Python, the kernel computes the geometry, and the operator gets a file their factory can build.
CADDIE routes the agent through parametric Python against an industrial-grade geometry kernel. The kernel computes the boundary representation. The agent is responsible for intent and dimensions; the kernel is responsible for the geometry being valid. The two responsibilities stay separate — the kernel resolves every fillet, boolean, and sweep deterministically, the way professional CAD packages have done it for decades.
Change thickness from 4 mm to 6 mm in the Python; re-run; the part regenerates with new fillets, new clearances, new mass. The STEP file carries the same parametric truth downstream. Mesh-only output has none of those properties — it is a snapshot, not a part.
Python diffs. STEP files diff (with a bit of help). A pull request can review a geometry change the same way it reviews a code change. Onshape, SolidWorks, and Fusion live behind proprietary file formats and per-seat licences — CADDIE puts the part alongside the firmware, the simulation, and the docs, inside the same project.
The agent thinks in words. The kernel thinks in geometry. CADDIE is the translation layer — the smallest Python wrapper that lets one talk to the other without losing the part in between.
The pipeline is intentionally small. There are no plugins to install in your CAD package, no cloud services to authenticate against, no GUI to learn. The agent writes Python; the runner exports the geometry; the viewer reloads. Each step is auditable, replaceable, and runs offline.
part.py — parametric Python with named constants for every dimension, written into the project's outputs/ folder. Diffable, editable, version-controlled.part.step, part.stl, part.glb, part.3mf, part.dxf + part.dfm.json — a kernel-truth manufacturability report — from a single source on every run.If you can write the prompt and read a STEP file, you have the full operator loop. Nothing else is required — no SolidWorks seat, no cloud service, no plugin. CADDIE wires into the agent you already use.
Three layers, all running locally on the operator's machine. The geometry kernel is industrial-grade — the same class of kernel that backs professional CAD packages. The runner emits five file formats from a single source. The viewer reloads the part live in any modern browser. No cloud round-trip; no proprietary file format trapping the geometry; no per-seat licence.
CADDIE writes parametric Python against an industrial-grade boundary-representation kernel — the same class that backs professional CAD packages. Named dimensions, manufacturability defaults, deterministic resolution of every fillet, boolean, sweep, and loft. Boundary-representation geometry, not mesh.
STEP (ISO 10303, parametric, downstream CAD) · STL (mesh, FDM/SLA) · GLB (binary glTF, web/viewer) · 3MF (mesh + metadata, newer printers) · DXF (2D drawings, laser/water-jet/sheet). All five emit from the same source on every run. No transcoding step.
Polls the latest GLB, reloads on change, prints bounding box and triangle count. Orbit · zoom · cyan-edge overlay. Runs in any modern browser; the operator opens a tab and the part is there, refreshing as the agent iterates.
The benchmark suite is the ground truth for whether a release is shippable. Each benchmark consists of a written prompt (the kind an operator would actually type), a reference part.py a human-quality agent should be able to produce from that prompt, and the resulting exports + DFM report. A release is green only when every benchmark regenerates cleanly with no DFM lint regressions.
CADDIE is built for teams that already live inside an AI coding agent. If your firmware, your simulation, and your docs all live in the same codebase and the only thing that lives somewhere else is the CAD, CADDIE pulls the CAD into the same place. If you are building an AI workflow that needs to emit a part as a side effect of reasoning — robotics, generative design, hardware co-pilots — CADDIE is the workflow that turns the agent's intent into a STEP file.
If your CAD lives in SolidWorks and your team is happy there, keep it there. CADDIE is for the cases where the CAD wants to live in code — and the agent wants to write the code.
Engagement by introduction or referral · Response within two business days