CADAM: a browser text-to-CAD app that compiles prompts into parametric OpenSCAD
CADAM is the open source text-to-CAD web application
At a glance
- What is it?
- CADAM turns plain-language descriptions and reference images into parametric OpenSCAD source, then renders and exports it in the browser through OpenSCAD compiled to WebAssembly. It is a good fit for people who want a parametric starting point they can edit by hand, and a poor fit for anyone expecting production-ready geometry from a single prompt.
- Who is it for?
- CADAM is worth adopting if you want a self-hosted, GPL-3.0 text-to-CAD front end whose output is readable OpenSCAD you can keep editing by hand, and if you already run Supabase or are willing to. Skip it if you need a supported desktop CAD kernel, guaranteed watertight geometry, or a permissively licensed component to embed in a closed product.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap CADAM fills: prompt in, editable OpenSCAD out
Most text-to-3D tools hand back a mesh. A mesh is a dead end for mechanical work: you cannot type a new value for a bore diameter and have the part rebuild. CADAM's README frames the project as "the open source text-to-CAD web application," and the output format it targets is the interesting part. The repository's benchmark write-ups describe each result as "fully parametric OpenSCAD, ready to export as .STL, .SCAD, or .DXF." So the artifact you keep is source code, not a binary blob. That is a narrower and more useful promise than "generate a 3D model." It suits mechanical engineers, robotics people and makers who already think in parameters and want a first draft they can open in an editor. It does not suit someone who wants a finished, manufacturable part from one sentence and no further work.
How the pipeline works: LLM to OpenSCAD, OpenSCAD to WebAssembly, Three.js to the screen
Three layers are visible in the material. First, generation: natural language and uploaded images go to a model that emits OpenSCAD source. Second, execution: the README lists OpenSCAD compiled to WebAssembly, which is how the app runs "entirely in your browser" without a server-side CAD kernel. Third, display: Three.js renders the preview, and the README notes a "Real-time Preview" plus "Parameter Extraction" that "automatically identifies adjustable dimensions." The topic list confirms the stack: react, wasm, openscad, stl, llms. The parameter extraction step is what makes the interactive sliders possible. The README also advertises "Smart Updates" described as "Efficient parameter changes without AI re-generation," which implies the generated script carries named variables that the UI can rewrite directly, so moving a slider does not spend another model call. The supplied material does not show the variable-naming scheme or what happens when a prompt produces geometry with no extractable parameters, and that is the seam I would probe first. The turbofan benchmark, for instance, lists only 2 dims against 10 colors, while the V8 engine lists 22 dims and 8 colors. A two-slider model is close to a static mesh with extra steps.
Getting it running: Node 20.19 or 22.12, Supabase, and what the README does not spell out
The badges pin the runtime: Node.js 20.19+ or 22.12+, React 19.1, and Supabase as the backend. There is a hosted instance at adam.new/cadam, and the README's first instruction is simply to try it there, which is the honest place to start because it costs nothing. Self-hosting is the moment the stack starts to matter. Supabase is not optional in the architecture as described: it is the backend badge, so a local run means either a Supabase project or a local Supabase instance, plus whatever keys the client build reads. The README excerpt supplied here does not include the clone URL, the package manager, the dev script name, or the environment variable names, so I am not going to guess them. Read the Installation section of the repository for the exact commands and the .env keys before you plan a deployment. The benchmark folder does give one concrete, verifiable command: benchmarks/render.sh renders the orbiting preview GIFs. That script is the cheapest way to confirm your OpenSCAD toolchain is wired correctly, because it exercises the same source files the app generates.
Where CADAM breaks down: prompt-to-script is a lossy step and the app cannot tell you it failed
The failure mode is inherent to the design. An LLM writes OpenSCAD, and OpenSCAD either compiles or it does not. A syntax error is easy to spot. A model that compiles but has a 2 mm wall where you asked for 4 mm, or a bore that intersects a boss, looks fine in the Three.js preview and is wrong. The README's benchmark table is a gallery of successes, which is exactly what a benchmark gallery is for, and it tells you nothing about the failure rate on ordinary prompts. Treat the first generation as a sketch. The second limitation is the export list: STL, SCAD, DXF. There is no STEP or IGES in the material, so CADAM will not hand your part to a downstream solid modeler in a boundary-representation format. STL is a triangle mesh, which is fine for printing and useless for a fillet operation in a parametric CAD package. If your workflow depends on STEP interchange, this is the wrong tool regardless of how good the prompt was.
The realistic alternative: write the OpenSCAD yourself, or use a script-first modeling stack
The honest comparison is not another text-to-CAD product, it is a text editor and OpenSCAD. CADAM's own output is OpenSCAD, so the question becomes what the model call actually buys you. If you already know OpenSCAD, writing a 20-line parametric part by hand is often faster than describing it, waiting for generation, and then correcting the result. What CADAM adds is the browser runtime (no OpenSCAD install), the parameter sliders derived from the script, and the image-to-model path for when you have a reference photo and no clear mental model of the geometry. The library support points the same way: BOSL, BOSL2 and MCAD are bundled, so generated scripts can call threads, gears and fasteners instead of reinventing them. If your parts are simple brackets and spacers, skip the AI layer and write the script. If you are staring at a photo of a turbofan and want a parametric skeleton in a minute, the generation step earns its place.
Maintenance, the GPL-3.0 boundary, and what a fork obliges you to think about
CADAM is licensed GPL-3.0 and the repository is not archived, with v0.3.0 tagged 2026-06-17 and a push to master on 2026-09-02, so the project is moving. Three releases in roughly six months (v0.1.0 in March, v0.2.0 in May, v0.3.0 in June) is a fast cadence, and fast cadences on a young codebase mean upgrade work. React 19.1 and a Node floor of 20.19 or 22.12 will move. The GPL matters more than the version churn for some readers. If you fork CADAM and ship a modified web app to users, the licence's copyleft terms apply to the derivative work; if you want to embed this generation pipeline inside a closed-source product, GPL-3.0 is a poor fit and you should get your own legal read rather than mine. Running the hosted instance at adam.new/cadam sidesteps the distribution question entirely, at the cost of sending your prompts and images to someone else's backend. That trade is the real decision, and it is a licensing and data question, not a technical one.
Editorial conclusion
CADAM is worth adopting if you want a self-hosted, GPL-3.0 text-to-CAD front end whose output is readable OpenSCAD you can keep editing by hand, and if you already run Supabase or are willing to. Skip it if you need a supported desktop CAD kernel, guaranteed watertight geometry, or a permissively licensed component to embed in a closed product. Before committing, read the exact clone and install commands in the README rather than the summary above, check which environment keys the client build expects, and run one benchmark prompt from benchmarks/ end to end to see how much of the generated parameter set survives an edit.
Community notes