CadQuery vs. OpenSCAD: Benchmarking Code-Based CAD Engines for LLM AI Agents

As generative AI transitions from text generation to physical artifact synthesis, autonomous agents rely on programmatic CAD engines to convert text prompts into precise 3D geometry. Evaluating the performance of CadQuery and OpenSCAD reveals stark trade-offs between Constructive Solid Geometry simplicity and pythonic Boundary Representation capability.

Key Takeaways

• OpenSCAD offers lower syntax complexity for basic shapes, making it easier for smaller LLMs to generate valid geometry without execution errors.
• CadQuery leverages Python and the Open CASCADE kernel, providing rich Boundary Representation (B-Rep) and STEP file exports necessary for professional engineering workflows.
• Benchmark analysis highlighted on Hacker News indicates that while OpenSCAD excels at rapid CSG prototyping, CadQuery dramatically reduces geometry hallucination rates in complex topological operations.

Why Programmatic CAD Runouts Are Critical for Autonomous Agents

Programmatic CAD engines provide determinism and executable feedback loops that allow Large Language Models (LLMs) to repair syntax errors and verify spatial geometry programmatically. Instead of predicting raw 3D mesh vectors or point clouds—which suffer from severe topological distortion—AI agents generate code that executes against a geometric kernel to produce production-ready CAD artifacts.

This code-first paradigm transforms 3D design into a software engineering problem. Agents can execute the generated script, catch runtime exceptions, inspect rendered images via visual language models, and continuously iterate until the part meets target dimensions. Selecting the optimal target language and underlying CAD kernel directly dictates an agent's success rate in spatial synthesis.

Architectural Comparison: Boundary Representation vs. Constructive Solid Geometry

CadQuery and OpenSCAD rely on fundamentally different geometric modeling paradigms that shape how LLMs express mechanical features. OpenSCAD utilizes Constructive Solid Geometry (CSG) evaluated via CGAL, whereas CadQuery operates on Boundary Representation (B-Rep) powered by the industrial Open CASCADE Technology (OCCT) kernel.

OpenSCAD's domain-specific language simplifies primitive operations like cubes, cylinders, unions, and differences. However, because CSG models geometry strictly through set operations, applying fillets or chamfers to arbitrary edges requires complex mathematical workarounds. CadQuery, by contrast, exposes Python Fluent APIs with powerful selector strings (e.g., .edges(">Z").fillet(2)), enabling LLMs to manipulate specific geometric features natively.

openscad // OpenSCAD Example: Equivalent primitive structure difference() { cube([50, 50, 10], center=true); cylinder(h=12, r=10, center=true, $fn=100); }

Benchmark Metrics: Code Syntax Validity and Execution Reliability

LLM agents achieve higher initial code validity with OpenSCAD, but CadQuery produces vastly superior industrial output when paired with execution feedback loops. Research data published by ModelRift demonstrates how model size and framework choice impact structural precision.

For simple geometric primitives (enclosures, brackets, mounting plates), OpenSCAD benefits from its minimal DSL grammar. LLMs generate valid OpenSCAD code on the first attempt more frequently because the language lacks complex standard libraries or stateful execution contexts. However, as prompt complexity scales to multi-part assemblies, thread generation, or precise edge modifications, OpenSCAD scripts quickly balloon into thousands of lines of manual geometric offsets.

CadQuery leverages Python's ecosystem, allowing agents to import standard math packages, use modular functions, and integrate directly with validation libraries. While LLMs occasionally hallucinate non-existent CadQuery selector methods, the execution feedback loop (catching Python AttributeError or kernel execution faults) allows agents to correct syntax errors rapidly before sending output to downstream rendering engines.

Native File Formats and Downstream Manufacturing Feasibility

CadQuery is the superior choice for professional manufacturing pipelines because it natively exports precise STEP vector geometry rather than tessellated polygonal meshes. OpenSCAD primarily targets mesh output formats such as STL, which break curved geometries into finite triangular facets.

In automated engineering workflows, exporting to STEP format preserves exact mathematical splines, cylindrical radii, and plane definitions. This allows downstream computer-aided manufacturing (CAM) tools, FEA simulation engines, and CNC software to interpret model boundaries accurately. Agents generating OpenSCAD code are largely restricted to 3D printing workflows unless secondary conversion tools convert polygonal meshes back into parametric shapes—a process prone to geometric degradation.

Strategic Selection Framework for Agentic Workflows

Selecting between CadQuery and OpenSCAD depends heavily on target hardware capabilities, required export formats, and the architecture of your LLM agent loop. Organizations deploying agentic CAD systems should evaluate their requirements against two primary operational profiles.

Choose OpenSCAD if your agent framework uses lightweight or fine-tuned localized LLMs (e.g., 7B-14B parameter models), focuses primarily on additive manufacturing (3D printing), and requires low execution latency for basic parametric enclosures.

Choose CadQuery if your system relies on advanced frontier models (e.g., Claude 3.5 Sonnet, GPT-4o), requires STEP exports for CNC machining or injection molding, and incorporates iterative Python execution sandboxes capable of feeding stack traces back into the prompt context for self-correction.