---
title: 'Arko-T: 4B Parametric CAD Text-to-Design Model'
url: https://www.emergentmind.com/topics/arko-t
type: topic
---

# Arko-T: 4B Parametric CAD Text-to-Design Model

Arko-T is a 4B-parameter text-to-design model for parametric CAD that maps natural-language intent directly into executable, editable CAD programs rather than render-oriented 3D shapes [2606.30429]. It is presented as a foundation-scale model trained end-to-end for text-to-design generation in parametric CAD, with the central objective of preserving the formal structure that makes a CAD artifact modifiable after generation. In the formulation given for the system, a text input $x$ is mapped to a design state $z$, where $z$ comprises a feature vocabulary $F$, named parameters $\Theta$, constraints $C$, a construction history $H$, and attachments $A$; a backend-specific decoder $D_{(b)}$ then produces a CAD program $p_{(b)}$, whose execution $E_{(b)}$ yields geometry $g$ and an execution log $\ell$ [2606.30429]. This formalization is used not only as a representational device but as the organizing principle for data curation, code normalization, training, and evaluation.

## 1. Problem setting and design-state formalization

Arko-T is positioned against a distinction between “text-to-3D” and “text-to-design” [2606.30429]. In the account given for the model, prior systems either generate a renderable mesh without editable structure or produce code that compiles yet does not preserve the named features, parameters, and construction logic required for downstream engineering modification. Arko-T therefore targets editable design state rather than geometry alone.

The formal object predicted by the model is the design state $z$. Its five components are specified explicitly: feature vocabulary $F$ includes elements such as holes, ribs, fillets, and shells; named parameters $\Theta$ include quantities such as radii, spacings, and thicknesses; constraints $C$ encode relations; construction history $H$ records procedural ordering; and attachments $A$ capture bindings such as face attachments [2606.30429]. The backend-specific decoder $D_{(b)}$ maps this state to a CAD program $p_{(b)}$, and the execution function $E_{(b)}$ returns both geometry and execution trace information.

This framing is significant because it relocates correctness from mere syntactic executability to state preservation. A plausible implication is that Arko-T treats CAD generation as a structured program synthesis problem whose target is an editable procedural artifact, not only a geometric endpoint. The paper’s emphasis on named parameters, explicit constraints, and ordered construction history also indicates that editability is operationalized as recoverable procedural semantics rather than as post hoc geometry manipulation [2606.30429].

## 2. Model architecture and optimization objective

At the architectural level, Arko-T is a 4 billion-parameter sequence-to-sequence transformer initialized from Qwen3.5-4B [2606.30429]. The exact layer count, hidden dimension, and attention-head configuration are not disclosed, and are described as mirroring the Qwen3.5-4B backbone. The paper instead emphasizes three task-specific specializations: a code decoder that autoregressively emits Build123d Python code, an execution module in the training pipeline that runs generated snippets in the Build123d kernel, and LoRA adapters injected into transformer layers during fine-tuning to specialize the model efficiently for CAD code generation [2606.30429].

The learning objective is token-level cross-entropy over normalized code sequences:
$$
L_{\text{code}} = - \sum_t \log P(\text{token}_t \mid \text{tokens}_{< t}, x).
$$
No auxiliary losses such as geometry reconstruction losses are added beyond execution-grounded filtering [2606.30429]. This is an important design choice: rather than jointly optimizing geometric similarity and program validity with multiple objectives, the system uses a single autoregressive code-generation loss while structuring the data pipeline so that valid execution and state alignment are already embedded in the supervision.

This suggests a deliberate separation between representation engineering and loss engineering. Instead of modifying the objective function to encode editability, the approach makes editability a property of the normalized training targets and of the execution-filtered corpus. For a CAD-generation setting, this is a consequential distinction, because it places the burden of semantic consistency on corpus construction and code canonicalization rather than on additional differentiable surrogate terms [2606.30429].

## 3. Training corpus, execution grounding, and normalization

The training corpus contains 1.3 million $(\text{prompt}, \text{program})$ pairs drawn equally from two sources [2606.30429]. One source consists of converted public datasets, including construction sequences from DeepCAD, SketchGraphs, and Fusion 360 Gallery, translated into Build123d scripts and paired with synthetic textual descriptions. The other source consists of curated open-source and proprietary designs: hand-authored Build123d programs spanning industrial parts, consumer goods, architecture, and personal-fabrication, each paired with human-written prompts.

Every candidate program is passed through the Build123d kernel, and only scripts that compile, execute without error, and produce a valid, non-empty solid are retained [2606.30429]. This “execution-grounded” filter ensures that the supervision signal excludes broken programs and non-manifold geometry. The claim made for this step is not simply that it improves code validity, but that it ensures correspondence between the text prompt and an editable design artifact.

A central novelty is code normalization around the five components of the design state [2606.30429]. Each program is rewritten so that named parameters $\Theta$ are hoisted into a top-of-file block with descriptive identifiers and units; feature vocabulary $F$ is expressed through canonical idioms, such as a hole represented as a `Circle`→`Cut` combination with a named radius; construction history $H$ follows a consistent sequence of sketch, extrude, secondary features, and finishing operations; and constraints $C$ and attachments $A$ are made explicit rather than implicit.

The training pipeline has two stages. Stage 1 is continual pre-training on CAD-related text, including APIs, documentation, and examples, to build vocabulary. Stage 2 is supervised fine-tuning on the normalized $(\text{prompt}, \text{code})$ pairs for one epoch with batch size 256, learning rate $2 \times 10^{-4}$, and 16 A100s, using LoRA [2606.30429]. Because all scripts used for supervision are guaranteed executable, the paper argues that the cross-entropy loss directly pushes the model toward valid, parameterized code aligned with the formal design state.

## 4. Benchmark protocol and reported performance

Arko-T is evaluated on Text2CAD-Bench, comprising 400+ prompts, along two axes: prompt style and part complexity [2606.30429]. Prompt style is divided into Geo and Pro, described respectively as lay descriptions and expert procedural instructions. Part complexity is divided into L1 single-feature and L2 multi-feature cases.

Before scoring, each generated script must pass a “validity gate”: it must compile and yield a non-empty solid [2606.30429]. Three primary metrics are then defined explicitly. Invalid Rate (IR) is the percentage of prompts that fail the validity gate, with lower values preferred. Chamfer Distance (CD) is computed between generated and ground-truth surfaces, scaled by $10^{-3}$, with lower values preferred:
$$
CD(P,Q)= \frac{1}{|P|}\sum_p \min_q \|p-q\|^2 + \frac{1}{|Q|}\sum_q \min_p \|q-p\|^2.
$$
Volumetric IoU is computed at $128^3$ voxels, with higher values preferred:
$$
IoU = \frac{|V_1 \cap V_2|}{|V_1 \cup V_2|}.
$$

Beyond these three, the paper reports a total of 12 metrics spanning editability, parameter fidelity, code executability under retries, feature-realization scores, geometry-overlap under local deformations, and inferential latency and cost [2606.30429]. Against seven frontier LLMs, Arko-T attains the best score on 8 metrics and the second-best on 3 more; the only case identified as remaining slightly behind the Gemini-3.5-flash baseline is multi-feature invalid rate.

| Benchmark slice | Reported metrics |
|---|---|
| L1 Geo | IR 4.40% (best), CD 2.46 (best), IoU 0.873 (2nd) |
| L1 Pro | IR 3.90% (best), CD 2.33 (best), IoU 0.868 (3rd) |
| L2 Geo | IR 12.20% (2nd), CD 4.92 (best), IoU 0.801 (2nd) |
| L2 Pro | IR 12.20% (2nd), CD 5.02 (best), IoU 0.780 (best) |

The paper also reports an inference cost of \$0.28 for the full benchmark on a local 4×A100 rig, characterized as 6× cheaper than the cheapest cloud API and more than 60× cheaper than the most expensive one; latency is given as 0.41 s per prompt, described as faster than all API baselines by an order of magnitude [2606.30429]. Within the scope of the benchmark, these results are used to argue that targeted design-level training at moderate scale can match frontier general-purpose models on structured CAD generation.

## 5. Ablation results and pipeline analysis

Although a full factorial ablation table is not reported, several controlled studies are described to isolate the contribution of major pipeline components [2606.30429]. Models trained without execution filtering exhibit invalid rates that are 3–5× higher and show 30–50% degradation in feature-realization metrics. Omitting parameter hoisting doubles average parameter-error percentage and produces code containing buried magic numbers that rescoring classifies as non-editable. Replacing half of the curated corpus with unconstrained open-source scripts lacking consistent feature ordering raises Chamfer Distance by more than 1.5× on L2 prompts.

These findings collectively support the paper’s central claim that data alignment to design state is not cosmetic preprocessing but a primary determinant of downstream editability and geometric fidelity [2606.30429]. In particular, the parameter-hoisting result indicates that explicit symbolic surfacing of dimensions is materially related to whether a generated artifact remains adjustable under API calls. Similarly, the sensitivity to inconsistent feature ordering suggests that construction history is being learned not merely as stylistic regularity but as an informative prior for CAD program synthesis.

A plausible implication is that the model’s performance depends on canonical procedural representation at least as much as on backbone scale. The reported results do not establish this as a universal law, but they do indicate that, for text-to-parametric-CAD generation, normalized procedural structure and execution-grounded supervision function as high-leverage inductive biases [2606.30429].

## 6. Representative generated programs and editability semantics

The paper includes representative prompt-to-code examples intended to show how Arko-T exposes design parameters and composes features in canonical order [2606.30429]. In a “Ventilated Plate” example, the prompt specifies a rectangular plate with five through-cut vent slots and ribs aligned over the slots. The generated Build123d code begins with named design parameters such as `plate_width`, `vent_slot_count`, `vent_slot_spacing`, `vent_slot_width`, `rib_width`, and `plate_thickness`, then proceeds through base plate sketch and extrude, slot construction, and rib placement via linear patterning. In a “Flanged Bracket with Holes” example, the prompt specifies an L-shaped profile, extrusion depth, two holes on a vertical face, and filleted outer edges; the generated code again begins with a parameter block and then follows sketch, extrude, hole placement, and finishing operations.

The examples are presented to illustrate three recurring properties of the normalized target format [2606.30429]. First, parameters are surfaced as named variables rather than embedded as anonymous literals. Second, feature creation follows the canonical history order established in the training pipeline. Third, features and attachments are made explicit, such as working on a selected face before placing holes.

These examples do not by themselves prove broad generalization, but they clarify the intended meaning of “editable” in this context. Editability is not treated as a vague user-facing attribute; it is instantiated procedurally through named parameters, explicit feature logic, and inspectable construction history. This is consistent with the benchmark’s use of editability-oriented metrics, including whether each named parameter remains adjustable under API calls [2606.30429].

## 7. Position in the text-to-CAD landscape

Arko-T is described as the first foundation-scale model trained end-to-end for text-to-design generation in parametric CAD, to the authors’ knowledge [2606.30429]. Its distinguishing contribution is not simply the generation of CAD code, but the explicit organization of the full pipeline around a formal design-state representation. Within that framing, data curation, code normalization, training supervision, and evaluation are all aligned to preserve features, parameters, constraints, construction history, and attachments.

A common misconception in this area is that executable code is sufficient evidence of successful CAD generation. The paper directly contests that view by distinguishing between programs that merely compile and programs that preserve the construction logic required for downstream modification [2606.30429]. Another potential misconception is that text-to-3D and text-to-design are interchangeable tasks; Arko-T is explicitly formulated around the premise that renderable geometry and editable parametric structure are different targets.

The broader significance claimed for the model is that moderate-scale, domain-specialized training can rival frontier general-purpose models for structured CAD generation when supervision is aligned to design state [2606.30429]. This does not imply that scale is irrelevant; rather, the reported evidence suggests that, in this domain, formalized procedural structure, execution grounding, and corpus normalization materially shape model capability. In that sense, Arko-T occupies a specific methodological position: it treats parametric CAD generation as a program-generation problem whose success criteria are executable validity, geometric fidelity, and retained editability within a formal design-state schema.

Source: https://www.emergentmind.com/topics/arko-t