The one-paragraph version
CADFS is a new system for getting vision-language models to write real, editable CAD programs. Until now, most AI for CAD history could only do two basic actions: draw a flat 2D profile, called a sketch, and push it into 3D, called an extrude. That produces simple prismatic blocks but not real engineered parts with rounded edges, drilled holes, bent tubes, or repeated bolt circles. The authors fix this by keeping models in Onshape's native programming language, called FeatureScript, instead of converting them to a simplified artificial code. They build a cleaning pipeline that turns Onshape's messy internal records into tidy executable programs, collect about 451,000 real user-designed models using 15 operation types, add plain-language instructions and images for each, and fine-tune a vision-language model called Qwen2-VL-2B to generate that code from text or from multi-view images. The resulting model makes more accurate, diverse, and detailed parts than prior text-to-CAD and image-to-CAD systems, including parts that need advanced operations like fillets, lofts, and revolves.
The problem they're solving, and why it matters
In engineering, a 3D part is usually not defined just as a surface. It is defined as a design history: the ordered list of parametric steps a designer took. A parametric step means an operation with adjustable numbers, for example extrude this rectangle 25.4 millimeters, or round this edge with radius 5 millimeters.
That history matters because it is editable. You can go back, change the hole diameter, move a sketch plane, or delete a pattern, and the solid updates. The alternative output, called boundary representation or B-rep for short, means the final faces, edges, and vertices that bound the solid. B-rep is good for manufacturing and rendering, but hard to edit as design intent.
Recent large language models and vision-language models, meaning models that take text and images as input and produce text or code as output, showed promise for writing CAD histories. But they were all trained on datasets that only contained sketch plus extrude, with only lines, circles, and arcs in the sketch. In practice that excludes operations that work on the evolving solid itself, such as picking a specific sharp edge to round, picking two faces to smoothly bridge, or repeating a feature around a circle. The paper argues the bottleneck is representation plus data: the old compact token sequence could only say “refer to step 3,” not “refer to the side edge created by extruding the junction of those two arcs.” Python wrappers like CadQuery added some flexibility but still used fragile references like “the third edge,” and were still trained only on sketch and extrude.
The key idea, in plain words
Do not invent a simplified toy language for the AI. Train it in the language real Onshape engineers already use: FeatureScript.
FeatureScript is expressive because it has structured queries. A query is a way to name a geometric thing by describing where it came from and what role it plays, much like a person would say “the edge formed by extruding the joint between those two wing arcs.” In the code this looks like a function that says: look at operation F5, look for swept side edges, look for edge-type entities, and if there are several, disambiguate by ancestors or neighbors.
Because that addressing is stable and human-like, the model can learn to do refinement and reuse, not just drawing and pushing. A concrete example from the paper is a toy rocket: draw a curved body profile with splines and spin it around an axis to make a rotational body, called a revolve; draw a wing profile with arcs and text and extrude it; find the wingtip edge from that extrusion and round it, called a fillet; copy the wing around in a circle, called a circular pattern; then bridge a rectangular wing face to a round base with a smooth transition, called a loft, and delete the helper body.
How it actually works, step by step
First, representation. Each model is stored as an executable FeatureScript program that runs in Onshape and reproduces the exact original geometry with full numbers and parameters.
Second, data cleaning. Onshape does not give you clean code for manual models. It gives an internal record with implicit definitions, mixed units, redundant math, and random names. The pipeline extracts the operation list, makes sketch definitions explicit — for example replacing “a point plus a direction” for a line with “start point to end point” — converts everything to millimeters, rounds numbers to two decimals, replaces dummy queries with meaningful ones, renames entities to ordered compact names like F0 for features and E0, E1 for entities, removes steps that do not affect the shape, and then recompiles. About 15 percent fail this recompile check and are discarded. The survivors form the 451k-model dataset covering 15 common operations from initial shaping to edge treatment to reuse.
Third, language annotation. There are no human captions at scale, so they use two large language models: an Annotator that drafts step-by-step instructions from the code plus FeatureScript documentation plus few-shot examples, and a Reviewer that checks operation order, numbers, which sketch region was selected, and terminology, and rewrites to plain user language without code variable names. This gives representation-aligned descriptions like “select the annular region between the 10.54 and 12.7 millimeter circles and extrude blind 158.75 millimeters,” rather than vague or normalized-coordinate descriptions from earlier work.
Fourth, model training. They fine-tune Qwen2-VL, an open vision-language model, in two stages: first on about 170k sketch-extrude-only designs to learn basic geometry, then on about 405k designs with all 15 operations after removing test splits and very long programs. The model is conditioned either on the text description or on a two-by-two grid of rendered views. Importantly, they keep real-world scale and tell the model the bounding-box bounds, center, and size in the prompt, because absolute size cannot be inferred from images alone.
What they showed — results, honestly, with limitations
They test on two sets: a 7,278-model DeepCAD test set that is sketch-extrude only, and a new roughly 9k-model test set with all 15 operations. They compare against Text2CAD, meaning token-sequence generation, and Cadrille, meaning Python CadQuery generation with the same Qwen2-VL-2B backbone.
On text-conditioned generation on the simple set, their model substantially lowers shape error. Median Chamfer Distance, meaning average closest-point mismatch between generated and true surfaces, drops from 0.10 for Cadrille to 0.06, and Edge Chamfer Distance, meaning the same mismatch measured only near sharp edges where industrial detail lives, drops from 22.5 to 8.2. Normal Consistency, meaning whether surface directions agree, coverage and distribution scores, meaning diversity and fidelity of the shape collection, also improve.
On image-conditioned reconstruction on the complex 15-operation set, they get 0.35 Chamfer Distance versus 3.26 for Cadrille, with much better edge accuracy. Their accuracy stays similar across simple and complex test sets, suggesting generalization beyond extrude.
Ablations show each piece helps: FeatureScript alone matches Python-code performance even with far less training data, adding the full 15-operation data gives the big jump on complex parts, and their own annotations cut Chamfer Distance by about 60 percent compared to old annotations on the same code. Supplying bounding-box size cuts image-based error by 76 percent in one test, and higher image resolution helps complex parts about twice as much as simple parts.
Limitations, stated plainly: Invalidity Ratio, meaning share of programs that fail to build a valid solid, is slightly worse than Cadrille on simple text tasks, 9 percent versus 3 percent, likely because the base model saw Python in pretraining but almost no FeatureScript. Text baselines cannot even be scored on the new complex set because old captions do not exist there. Image-to-history remains much harder than text-to-history. Failure cases include skipping fillets, filleting the wrong edge, garbled embossed text from images, and falling back to many small extrudes instead of using a pattern. The comparison to mesh generator TRELLIS is very favorable to CADFS, but that is expected since meshes lack parametric intent and often produce non-watertight or over-smoothed results. Some details like exact compute tradeoffs and coverage outside Onshape-style mechanical parts remain unclear.
Why this might matter to me
For spatial reasoning in LLMs and VLMs, this is evidence that language-first models can learn to refer to 3D structure by history and topology, not just by coordinates. The query idea — name a thing by origin plus role plus type plus disambiguation — is a template for grounding language in evolving worlds, and the ablation showing that aligned captions matter more than model size, 2B matching 8B, is directly relevant to how you prompt and supervise spatial models.
For world models, the design history is a compact causal world program: actions with parameters, intermediate geometry, and dependencies. Learning to predict valid next operations that still compile is a stricter test of physical plausibility than predicting pixels or points, and the scale-aware prompting shows how to separate what vision can see from what must be given as state.
For text-to-CAD and parametric geometry, this moves the field from toy prisms to realistic workflows with revolves, sweeps, lofts, shells, holes, booleans, chamfers, fillets, mirrors, and patterns, all editable and in true millimeters. If you care about controllable CAD, the code-plus-query representation is more useful than triangle soup.
For 3D generation and scene representation, the message is that B-rep or mesh fidelity alone is not enough. A history representation preserves intent, reuse, and editability, and it interfaces naturally with renderings, point clouds, and language. The failure modes also point to next steps: better visual encoders for fine edges and text, and reinforcement or execution feedback to prefer higher-level parametric structure over low-level extrusion hacks.
Terms worth knowing
Design history means the ordered parametric steps that build a part, as opposed to just the final shape. Sketch means a 2D profile made of lines, circles, arcs, ellipses, splines, Bezier curves, or text. Extrude means pushing a sketch region straight to make a solid. Revolve means spinning a profile around an axis to make shafts or housings. Sweep means moving a profile along a curve to make tubes. Loft means smoothly interpolating between different profiles. Fillet means rounding an edge. Chamfer means beveling an edge flat. Shell, hole, boolean, pattern, mirror, and transform are ways to hollow, cut, combine, repeat, symmetrize, or move solids. B-rep means boundary representation, the final faces, edges, and vertices. FeatureScript means Onshape's native CAD programming language. Query means a structured reference to an edge, face, or body by its creating operation, topological role, type, and disambiguation data. VLM means vision-language model. Chamfer Distance, Edge Chamfer Distance, Normal Consistency, Coverage, Minimal Matching Distance, Jensen-Shannon Divergence, and Invalidity Ratio are the paper's measures of shape accuracy, edge accuracy, surface orientation, diversity, distribution match, and how often generated code fails to build.