Can It Actually Work? Synthesizing Functional CAD Mechanisms

Wenqian Zhang; Yangyi Huang; Zigeng Xu; Weiyang Liu; Zhen Liu

cs.CVOct 19, 2026

Can It Actually Work? Synthesizing Functional CAD Mechanisms

Authors: Wenqian Zhang, Yangyi Huang, Zigeng Xu, Weiyang Liu, Zhen Liu

Organizations: The Chinese University of Hong Kong (Shenzhen) · The Chinese University of Hong Kong

Abstract

While LLM agents can generate visually plausible CAD assemblies, these designs often fail to fulfill their intended physical functions. We study functional CAD design, a setting where agents interpret underspecified requests to construct and iteratively revise mechanisms that satisfy functional requirements in physical simulation. Verifying these requirements is nontrivial: different candidate mechanisms may realize the same function through entirely different components, controls, and operating sequences. To bridge this gap, we propose FunCAD-Harness, a framework that translates abstract requirements into candidate-specific physical tests and uses simulation feedback to guide design revisions. To systematically evaluate this capability, we introduce FunCADBench, a benchmark spanning 46 mechanism families with interdependent and multi-step operations. Experiments across frontier LLM agents show that FunCAD-Harness exposes subtle mechanical failures invisible to visual inspection, substantially improving functional success rates over standard simulation-augmented baselines. Ultimately, our work marks a step toward CAD agents capable of translating human intent into working mechanisms.

Figures & tables

Figure 1: Functional CAD design from user request to physical prototype. In the illustration, a user request for cup access is decomposed into functional goals that guide agent-based CAD construction and simulation-driven refinement. The resulting design is fabricated and operated by a human, with the printed prototype shown at maximum lift and during cup retrieval.

Figure 3: Mechanisms built by LLM agents in our experiments. The 75 assemblies cover all 46 FunCADBench families and are rendered from their delivered CAD geometry (arranged for display, not to scale); 38 of them pass the full FunCAD-Harness evaluation.

Figure 4: Gear-transmission cost. Native time is extrapolated from its recorded mean.

Figure 5: Overview of FunCAD-Harness, illustrated with a releasable reduction winch (Task 42).

Figure 6: Task success and mechanical demand coverage. (a) Tasks share an ordering across models. Colored segments indicate success, and gray segments indicate no recorded success. Individual outcomes appear in Table 8 . Time, tokens, and estimated constructor API cost are per-task medians. API cost covers recorded constructor usage and accumulates across attempts in the history setting (Appendix E.3 ). (b) Success weighted by requirement grades 1–3 for each demand axis, normalized by the total weight over all 46 tasks (Appendix E.5 ). Task grouping and demand-weighted scores use the four single-attempt settings.

Setting	Provided support	Astra	Grok
Requirements only	Requirements and agent-chosen verification	1/46	3/46
Simulation tools	Requirements, simulator, and tool guidance	8/46	10/46
Binary feedback	Full workflow with pass/fail simulation feedback	0/46	8/46
No constructor vision	Full harness without constructor visual access	20/46	18/46
Full harness	Tests of required functions and diagnostic feedback	22/46	19/46

Table 2: End-to-end completion on 46 functional CAD tasks under independent final evaluation. Success-set overlaps appear in Appendix F .

Figure 7: Function-blocking interference in Astra designs produced without harness feedback. (a) The bicycle’s steering assembly intersects the fixed frame (Task 7, requirements-only ). (b) The clock’s hour wheel overlaps the alarm lever despite separate escapement and striker tests (Task 9, simulation-tools ). Red circles mark interference, and dashed silhouettes indicate intended poses. The clock inset uses schematic hand placement and sleeve length.

Figure 8: Grok repairs re-locking and local interference in a spring-return door latch (Task 33).

Figure 9: Tool use and execution time on 41 matched tasks. (a) Distribution of constructor tool calls. (b) Distribution of recorded standard-tool execution time. Simulation and cost probes are grouped together, and Concurrent denotes overlapping execution across categories. Shares are computed within each task and averaged with equal task weights. Call annotation, filtering, and timing details appear in Appendix E.6 .

Panel of Figure 10 — Figure 10: Selected printed prototypes. (a) Front and rear views of the two-digit counter (Task 19). (b) Gravity timer (Task 21). (c) Initial configuration of the open-ended cup-access machine. The pen marks the target cup at the rear. Figure 1 shows the raised configuration and retrieval. Task numbers follow Appendix B .

Appendix figures & tables23 assets

Supplementary material from the paper’s appendix.

Appendix

Setting	Model-visible materials and feedback
Requirements only	Functional requirements and ordinary construction tools; agents may implement their own verification.
Simulation tools	The same requirements, with the simulation environment, starter code, and API guidance; agents select and interpret their own tests.
Full harness	Simulation support, independent requirement-level test binding, and diagnostic execution feedback throughout revision.
Binary feedback	The same harness workflow, with pass/fail simulation feedback in place of diagnostic details.

Appendix

Table 3: Model-visible support in the four harness settings.

Mechanism	Functional requirements	Operations and observations
1 Hinged toolbox	Open the lid to the target angle against a physical stop, then close it; keep the lid attached and the hinge pin axially retained throughout.	Actuate the handle or lid edge; record lid angle, stop contact, and axial hinge-pin displacement.
2 Rack-and-pinion gate	Raise and lower the gate, including under load, with the required travel per handle revolution while maintaining guidance and respecting travel limits.	Turn the handle; record input rotation, gate travel, load, guide retention, and travel limits.
3 Four-bar wiper	Convert continuous input rotation into repeated sweeping with the required angular range, consistent return, and intact linkage connections.	Rotate the drive shaft; record sweep extrema, return position, cycle count, and accumulated drift.
4 Hand-cranked egg beater	Drive both beaters in opposite directions at the required speed ratio, including under the specified resistance.	Turn the handle; record handle and beater angles and speeds, resisting loads, and shaft retention.
5 Self-locking utility knife	Extend the blade to two positions, retain each position after release, and permit unlocking and full retraction.	Operate the slider; record extension at each position, displacement after release, and the final tip position.
6 Folding drying rack	Unfold both frames and raise the drying surface, stand stably, and fold into the required storage configuration without losing support.	Operate the folding controls; record frame angles, drying-surface height, ground support, and folded dimensions.

Appendix

Table 4: The 46 mechanism families in FunCADBench, their functional requirements, and the corresponding operations and observations.

Input requirement	Functional test template	Candidate-specific simulation test
Task 41: synchronized parallel gripper — Fable, r02
A single input opens and closes both jaws with symmetric motion and parallel gripping faces.	Motion and guidance. Operate the normal input; check each jaw’s travel, synchronization, face parallelism, guide deviation, and available opening.	Apply force to the central plunger along its sliding axis, capped at 35 N. Measure the actual jaws: each travels at least 6 mm; synchronization and guide errors stay within 0.5 mm, parallelism within 0.01 rad, and the released opening reaches at least 50 mm.
Hold the test piece without slipping or falling under the specified load.	Loaded holding. Apply a load to the grasped piece; verify actual load, minimum jaw–piece contact force, and three-dimensional slip relative to the jaws.	Apply 5 N tangentially to the free test block during 1–3 and 5–7 s. Require at least 10 N grip force, measured mean load of at least 4.5 N, and slip of at most 1 mm in each loaded phase.
Grasp, release, and repeat using the same operating input.	Repeated use. Execute two close–hold–release cycles in one trial, retaining the workpiece state between cycles. Apply the same checks to both cycles.	The repeated_loaded_grip trial lasts 8 s. Plunger targets are +40 mm for closing and 0 mm for opening; physical contact limits actual travel. The second cycle begins at 4 s without resetting the block. All 16 checks are evaluated on this continuous trial.
Task 33: spring-return door latch — Grok, r06
Turning the handle retracts the latch so the door can open.	Unlocking and opening. Retract the latch through handle operation before opening the door; observe latch protrusion and door position.	Bind inputs to the actual handle and door hinges, with torque caps of 3 and 12 N m. Target a handle angle of $-70^{\circ}$ and a door opening of 0.4 rad. Require latch protrusion of at most 8 mm and door-position error of at most 0.12 rad.

Appendix

Table 5: From input requirements to functional test templates and recorded candidate-specific simulation tests. Prompt clauses are condensed; numerical settings refer to the named candidate and revision.

Figure 11: Fable’s design trajectory for the synchronized parallel gripper (Task 41). Construction and development tests establish the initial grasping behavior; formal feedback exposes a failure during repeated use. The agent revises the contact geometry, workpiece support, and permitted input effort before the final candidate passes both loaded grasp–release cycles and the source-geometry audit.

Figure 12: Grok repairs the twin-cylinder linkage (Task 39): enlarge the flywheel, clear the resulting cylinder contact, and verify repeated piston motion.

Interaction model	Wall/step (s)	Sim. time (s)	Total wall (s)
Native tooth contact (light)	0.894	6.0	5,364
Equivalent spur gears (light/medium/heavy)	0.113–0.117	1.2	136–141

Appendix

Table 6: Task 25 reducer timings (1 ms step; standard test budget: 300 s). Different designs and simulated durations preclude a controlled speedup comparison.

Role	Model identifier	Wrapper	Requested reasoning setting
Constructor	claude-fable-5-1-thinking-high	Cursor	High
Constructor	cursor-grok-4.6-xhigh	Cursor	Extra high
Constructor	kimi-code/k3	Kimi CLI	High *
Constructor	gpt-6-astra	Codex	High
Final evaluation agent	gpt-6-astra	Codex	Medium

Appendix

Table 7: Generation-agent and final-evaluation configurations

ID	Mechanism	Astra	Kimi	Fable	Grok
1	Hinged toolbox	—	—	—	—
2	Rack-and-pinion gate	$\checkmark$	$\checkmark$	$\checkmark$	$\checkmark$
3	Four-bar wiper	$\checkmark$	$\checkmark$	$\checkmark$	$\checkmark$
4	Hand-cranked egg beater	$\checkmark$	$\checkmark$	$\checkmark$	$\checkmark$
5	Self-locking utility knife	$\checkmark$	—	$\checkmark$	$\checkmark$
6	Folding drying rack	—	—	$\checkmark$	—

Appendix

Table 8: Task-level recorded completion in the four single-attempt full-harness configurations. A check mark denotes completion under formal evaluation; a dash denotes no recorded completion, including unfinished evaluation. Each configuration has one independent attempt per task.

Axis	Grade 1	Grade 2	Grade 3
Motion	Direct operation of one degree of freedom	One input–output relation	Multiple stages or coordinated outputs
Structure	Local support or connection	One jointly constrained chain	Multiple constraint groups sharing parts or state
Function	One basic operation and return	Coupled functions or operating conditions	Interdependent functions or conditional states
Contact	Continuous support or transmission	Engagement/release or force-dependent function	Several contacts coordinated across states
Geometry	Local fit, alignment, or retention	Swept clearance or one meshing relation	Interacting clearances, retention, or meshing constraints

Appendix

Table 9: Anchors for the three mechanical-demand grades.

Task	M	S	F	C	G	Task	M	S	F	C	G
1	1	1	1	1	1	24	2	2	2	2	2
2	2	2	2	1	2	25	3	2	2	1	3
3	2	2	1	1	2	26	1	1	1	1	1
4	3	2	2	1	2	27	1	1	1	1	1
5	1	2	3	3	2	28	1	1	1	1	1
6	3	3	2	2	3	29	1	1	1	1	1

Appendix

Table 10: Task demand grades used in the weighted-completion analysis. Columns M, S, F, C, and G denote motion, structure, function, contact, and geometry. Task IDs follow the mechanism catalog.

Complexity	Tasks	Astra	Kimi	Fable	Grok
Low	11	9/11	8/11	9/11	9/11
Medium	20	12/20	6/20	18/20	10/20
High	15	1/15	0/15	5/15	0/15

Appendix

Table 11: Recorded completion within the benchmark’s original complexity classes. These classes were not constructed by binning the radar scores.

	Astra			Grok
Setting	Passed	Shared	Only	Passed	Shared	Only
Requirements only	1/46	1	0	3/46	3	0
Simulation tools	8/46	7	1	10/46	8	2
Full harness	22/46	—	—	19/46	—	—
Binary feedback	0/46	0	0	8/46	7	1

Appendix

Table 12: Whole-task successes and their overlap with the full harness. Shared counts tasks solved by both the row’s workflow and the full harness for the same model; Only counts successes unique to that workflow relative to the full harness.

Setting	Simulation support	Requirement-level testing	Visible evidence
Requirements only	Agent implements any simulation it chooses to use.	Agent chooses its own checks.	Outputs of agent-written checks.
Simulation tools	Simulator, starter code, and tool guidance are supplied.	Agent chooses its own checks.	Agent’s simulation outputs and geometric analyses.
Binary feedback	Harness constructs and executes candidate-specific tests.	Required functions remain part of the evaluation workflow.	Pass/fail outcomes; execution and validation diagnostics are hidden.
Full harness	Harness constructs and executes candidate-specific tests.	Required functions remain part of the evaluation workflow.	Failed checks, measured discrepancies, and physical-validity diagnostics.

Appendix

Table 13: Support and feedback available during construction.

		Astra				Grok
ID	Mechanism	Req.	Sim.	Bin.	Full	Req.	Sim.	Bin.	Full
1	Hinged toolbox	—	—	—	—	—	—	—	—
2	Rack-and-pinion gate	—	—	—	$\checkmark$	—	—	—	$\checkmark$
3	Four-bar wiper	—	—	—	$\checkmark$	—	—	—	$\checkmark$
4	Hand-cranked egg beater	—	—	—	$\checkmark$	—	—	—	$\checkmark$
5	Self-locking utility knife	—	—	—	$\checkmark$	—	—	—	$\checkmark$

Appendix

Table 14: Recorded completion by task and setting. Req.: requirements only; Sim.: simulation tools; Bin.: binary feedback. A check mark denotes recorded whole-task completion; a dash denotes no recorded completion, including incomplete evaluation or partial delivery.

Case	Agent action	Observed evidence	Implication and remaining scope
Task 36 Astra Geneva indexing table	Adds a spring-loaded roller detent after station drift; tests obstructions near entry and exit; relieves slot mouths after a swept-geometry check.	The constructor reports eight $90^{\circ}$ steps, dwell holding under disturbances, and recovery after obstruction in its own simulations.	Task-relevant experiments lead to concrete mechanical changes. These local results do not establish whole-task completion in the reported evaluation.
Task 9 Astra Mechanical alarm clock	Tests the escapement for 600 simulated seconds and tests the striker separately; revises gear phasing and local clearances.	The escapement advances approximately ten revolutions. The delivery explicitly leaves the integrated alarm sequence unverified; the hour wheel also interferes with the alarm lever.	Subsystem evidence leaves a composition gap: setting, triggering, and stopping the alarm must all preserve timekeeping. See Fig. 7 b.
Task 13 Grok Ratchet screwdriver	Replaces a numerically invalid 1.40-second loaded, two-stroke test with a 0.20-second stepping test.	The new run returns 21 finite samples, but the bit remains nearly stationary. The original drive and return-stroke checks are not repeated.	Restoring executable simulation narrows the tested behavior. The agent identifies the result as a smoke test and does not claim functional success.

Appendix

Table 15: Testing and revision in the simulation-tools setting. Agent-written checks are distinguished from recorded whole-task completion.

Case	Agent action	Evidence and outcome	What the case shows
Task 1 Astra Hinged toolbox	Tests rest and opening with opposite torque signs. Reverses the hinge’s body ordering after only the reverse-direction opening test passes.	A subsequent positive-torque opening test passes. The complete two-cycle operation remains unverified; the agent delivers partial results.	Carefully chosen binary tests can distinguish an input-direction error from other explanations. Resolving one local cause does not establish the full operating sequence.
Task 12 Grok Nail clipper	Uses its own geometry and linkage calculations to investigate input direction, excessive follower travel, and changes in the four-bar solution branch; revises the mechanism.	The revised design obtains a recorded whole-task pass. Several coupled design changes precede this result.	Restricted feedback still permits successful diagnosis when independent analysis supplies the missing information. This success cannot be attributed to a single parameter change.
Task 33 Grok Spring-latch door lock	Measures clearances and revises hinges, handle bearings, cam orientation, latch geometry, and the strike plate after repeated binary failures.	The agent finds geometric problems, but the returned failures do not confirm which defect caused rejection. No whole-task completion is recorded.	Useful inspection can coexist with unresolved failure localization. The full-harness repair in Fig. 8 instead tracks relocking checks and then residual interference.

Appendix

Table 16: Diagnostic strategies under binary feedback. Geometric and kinematic calculations are the agents’ own analyses, not hidden simulation traces.

Model	Completed	Partial delivery	Budget exhausted	Evidence required
Astra	0	43	0	3
Grok	8	0	36	2

Appendix

Table 17: Recorded termination states under binary feedback, with 46 runs per model. Categories are mutually exclusive. Evidence required denotes a recorded unresolved evidence state.

Figure 13: Mechanisms completed by Astra without visual access for the constructor.

Figure 14: Mechanisms completed by Grok without visual access for the constructor.

		Astra		Grok
ID	Mechanism	With vision	No vision	With vision	No vision
1	Hinged toolbox	—	$\checkmark$	—	—
2	Rack-and-pinion gate	$\checkmark$	$\checkmark$	$\checkmark$	$\checkmark$
3	Four-bar wiper	$\checkmark$	—	$\checkmark$	$\checkmark$
4	Hand-cranked egg beater	$\checkmark$	$\checkmark$	$\checkmark$	$\checkmark$
5	Self-locking utility knife	$\checkmark$	$\checkmark$	$\checkmark$	—

Appendix

Table 18: Task-level recorded completion of single-attempt Astra and Grok full-harness runs with and without visual access for the constructor. A check mark denotes completion under formal evaluation; a dash denotes no recorded completion, including unfinished evaluation. Each setting has one independent attempt per task; the With vision columns reproduce the Astra and Grok columns of Table 8 .

Figure 15: Mechanisms completed by Grok in pass@8 without shared records.

ID	Mechanism	Single	Passing runs	Any of 8
1	Hinged toolbox	—	2/8	$\checkmark$
2	Rack-and-pinion gate	$\checkmark$	7/8	$\checkmark$
3	Four-bar wiper	$\checkmark$	7/8	$\checkmark$
4	Hand-cranked egg beater	$\checkmark$	7/8	$\checkmark$
5	Self-locking utility knife	$\checkmark$	0/8	—
6	Folding drying rack	—	0/8	—

Appendix

Table 19: Task-level recorded completion of Grok with eight independent full-harness attempts per task, without access to records from other attempts. Single reproduces the Grok column of Table 8 ; Passing runs counts attempts that complete the task under formal evaluation; Any of 8 marks tasks completed by at least one attempt. A dash denotes no recorded completion, including unfinished evaluation.

Panel of Figure 16 — Figure 16: Printed prototypes for piston motion, code-controlled locking, and ball dispensing. (a–b) Task 17: two crank positions of the piston linkage. (c) Task 18: three numbered code wheels and the locking bar. (d) Task 20: the loading channels, dispensing slider, and receiving tray.

Mechanism Design

Mechanism design studies rules for allocating resources and shaping incentives when participants hold private information or act strategically.

See all 137 papers

Physics-in-the-Loop: A Hybrid Agentic Architecture for Validated CAD Engineering Design
May 19, 2026Elias Berger, Muhammad Usama, Jan Mehlstäubl +2Text-to-CAD Generation
Dresden University of Technology, Dresden, Germany · MAN Truck & Bus SE, Munich, Germany · German Research Center for Artificial Intelligence, Kaiserslautern, Germany +1
LMBuild: Evaluating LLM Agents for Generating Buildable and Functional Structures
Oct 3, 2026Jiateng Liu, Rushi Wang, Cheng Qian +9LLM Agent Evaluation AI Agent Benchmarks
University of Illinois Urbana-Champaign
COSMO-Agent: Tool-Augmented Agent for Closed-loop Optimization,Simulation,and Modeling Orchestration
Apr 7, 2026Liyuan Deng, Shujian Deng, Yongkang Chen +6LLM Agent Orchestration Parametric CAD Modeling
Northwestern Polytechnical University · Shanghai Artificial Intelligence Laboratory

May 19, 2026J/K move · Enter open · S save

Physics-in-the-Loop: A Hybrid Agentic Architecture for Validated CAD Engineering Design

Elias Berger, Muhammad Usama, Jan Mehlstäubl, Bernhard Saske+1

Dresden University of Technology, Dresden, Germany · MAN Truck & Bus SE, Munich, Germany · German Research Center for Artificial Intelligence, Kaiserslautern, Germany+1

Text-to-CAD Generation

Open paper AskPDF arXiv

Large Language Models (LLMs) can generate Computer-Aided Design (CAD), yet lack physical comprehension required for reliable engineering design. Instead of attempting to implicitly learn physical laws from data, we propose a Hybrid Agentic-Physical Architecture that embeds validated knowledge-based engineering tools directly into the decision making loop of autonomous AI agents. In this framework, engineering design is formulated as a closed-loop, sequential decision making process guided by explicit physical verification. Based on a load case, dedicated agents iteratively plan, generate, evaluate, and revise engineering designs using knowledge-based tools as a feedback signal. We introduce a benchmark dataset and metrics for assessing functional validity in generative CAD. Our system generates more complex and physically verified designs, with a 4.2 increase in structural complexity and improving compile rate by 3.5% compared to similar agentic methods. The codebase, prompts and dataset will be made publicly available to support reproducibility and future research.

Abstract

Mechanism Design

Explore similar work

Physics-in-the-Loop: A Hybrid Agentic Architecture for Validated CAD Engineering Design

LMBuild: Evaluating LLM Agents for Generating Buildable and Functional Structures

COSMO-Agent: Tool-Augmented Agent for Closed-loop Optimization,Simulation,and Modeling Orchestration