MAC (Multi-Agent CAD): four agents, a constrained test-time loop, and a token budget that drops by two orders of magnitude

The problem is not generating CAD code, it is paying for the thinking

Large language models can already emit build123d or CadQuery scripts from a description. The expensive part is the reasoning loop around that emission: an agent that inspects its own output, re-reads the error, rewrites the script, and repeats. Each iteration resends the accumulated context, so cost grows faster than the number of attempts. The README puts the baseline at 103.9M tokens and ¥125.69 across ten benchmark prompts, and MAC at 896k tokens and ¥9.67. That is the claim in one line: same task, same prompts, roughly two orders of magnitude less spend.

MAC is aimed at engineers who want a printable STEP file from a sentence, and who care about the bill. The gallery is deliberately physical: the parts were printed, not just rendered. Ten benchmark parts (P1 to P10) reuse prompts from earthtojake/text-to-cad so the comparison is apples to apples, and ten show parts (S1 to S10) are original to this project. If you are evaluating text-to-CAD as a prototyping shortcut rather than a replacement for a CAD kernel, this is the target audience.

Four agents, one constrained loop, and a STEP file at the end

The repository describes a decoupled multi-agent framework: four agents collaborating, coordinated through a graph. The topics list names langgraph, which is the orchestration layer, and aider, which is the code-editing layer. build123d sits underneath as the modelling library, with OpenCascade as the geometry kernel and STEP as the output format. The name of the project, constrained test-time compute, describes the second half of the design: rather than letting an agent iterate until it converges, the pipeline bounds how much compute is spent per attempt.

That bound is where the token savings come from. A naive agent loop that keeps the full history of every failed script grows its prompt with each retry. Constraining test-time compute means the loop terminates on a budget rather than on a success signal, which caps the worst case. The README's per-prompt cost table shows the spread this produces: P8 (centrifugal impeller) drops from ¥32.75 to ¥1.20, a 27.3x reduction, while P6 (aerospace clevis bracket) drops from ¥15.21 to ¥3.10, only 4.9x. The framework is not uniformly cheap. It is cheapest on the prompts where the baseline wandered.

The output format matters as much as the pipeline. STEP is a boundary representation, not a mesh, so the result is a solid model with real faces and edges. The articulable examples make this concrete: a ball-in-cage toy described as a 40 mm cube cage with a 16 mm radius spherical hollow, a 15 mm ball with 1 mm clearance, and six 12 mm through-holes. Those clearances are geometric relationships between separate bodies in one file, which a mesh pipeline cannot express the same way.

Installation: conda first, and a numpy pin you have to work around

The documented install is four commands. Clone the repository, create the conda environment from environment.yml, activate it, then install aider separately:

git clone https://github.com/Pan-Chera/Multi-Agent-CAD cd Multi-Agent-CAD conda env create -f environment.yml conda activate multi_agent_cad pip install --no-deps "aider-chat==0.82.3"

The README is unusually candid about why that last line exists. Every aider-chat release on PyPI pins numpy==1.26.4, while build123d requires numpy>=2,<3. Conda's pip subprocess cannot bypass the pin, so aider-chat is left out of environment.yml entirely and installed with --no-deps afterward. The README's position is that the aider pin is over-cautious upstream and that 0.82.3 imports cleanly on numpy 2.x.

For pure pip users the README gives a venv workaround, described as verified on macOS arm64 with Python 3.11. The snippet in the supplied material is truncated at the pip line, so the full sequence is not visible here. If you are not on that platform, treat the pip path as unverified and prefer conda. Python 3.11 is the stated target, not a range.

The pass rate measures features, not tolerances

99.3% is 140 of 141 features, and the baseline is 97.9%, or 138 of 141. The denominators are identical, which is a good sign for comparability, and the prompts are shared with the baseline project, which is better. But the metric is feature pass rate. A part can have every named feature present and still be wrong in ways that matter to a mechanical engineer: a hole at 5.9 mm instead of 6.0 mm, a wall 0.3 mm thinner than specified, a fillet that is geometrically valid but not the one you asked for.

This is the honest limitation of the whole category, and MAC does not claim to solve it. Nothing in the supplied material describes dimensional tolerance checking, GD&T validation, or a fit analysis against a mating part. The articulable models show that clearances are controllable to the level the prompt specifies (0.4 mm radial for the gyroscope, 1 mm for the ball-in-cage), but that is the model following an explicit number in the description, not the framework deriving a tolerance.

The second limitation is the baseline itself. The head-to-head is against CAD Skills on ten shared prompts. That is a narrow comparison. If your parts look nothing like a flange, an L-bracket or a stepped shaft, the reported ratios tell you very little about your workload, and the per-prompt spread from 4.9x to 32.9x suggests the savings are highly prompt-dependent.

Against CAD Skills: fewer attempts versus more context

The README's own comparison table names the alternative: earthtojake/text-to-cad, referred to as CAD Skills. The difference in approach is visible in the numbers rather than stated outright. CAD Skills reaches 97.9% feature coverage on 103.9M tokens. MAC reaches 99.3% on 896k. Higher accuracy at a fraction of the spend implies the baseline is spending tokens on something that does not convert into correctness, most likely repeated context in a longer agent loop.

So the choice is not which model is smarter. It is whether you want an agent that keeps trying with full history, or one that is budgeted and stops. The first is more likely to grind through a hard part given unlimited spend. The second has a predictable ceiling. For a ten-part benchmark run the difference is ¥116. If you are generating thousands of variants in a design sweep, the difference is the difference between a viable service and an unviable one.

There is a third option worth naming: skip the agent layer and write the build123d script yourself. That is free, exact, and slower for the first part and faster for the hundredth. MAC's value is concentrated in the exploratory phase, where you do not yet know what you want and the cost of a wrong answer should be near zero.

Licence, maintenance and what an upgrade actually costs

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication I can state from the supplied material; whether MIT is compatible with your organisation's policies, or with the licences of build123d, OpenCascade, aider-chat and langgraph as you intend to combine them, is a question for your own review, not something this article can settle.

Maintenance cost is dominated by the dependency conflict, not by the project's own code. The aider-chat pin is upstream and has persisted across every PyPI release according to the README, so the --no-deps workaround is not a one-time fix. Any future aider version you pin will carry the same numpy==1.26.4 declaration, and any future build123d release that raises its numpy floor widens the gap. Budget for re-checking that pairing on every upgrade of either package.

The last push to the repository is dated 2026-08-13, and the only listed release is ui-demo-v1, a web UI walkthrough video dated 2026-08-04. There is no tagged version of the framework itself in the supplied material, which means there is no version number to pin against and no changelog to read before upgrading. Track the main branch and read the diff.

Editorial conclusion

Adopt MAC if you already have a conda workflow, a Qwen-class API key, and a need for STEP files that a slicer can open without repair. Do not adopt it if your parts are defined by tolerances, fits or GD&T callouts, because the pipeline optimises for feature presence, not dimensional correctness. Before committing, verify two things: that the pip install --no-deps 'aider-chat==0.82.3' step resolves on your platform, and that the agent count and token accounting in docs/qwen3.7_token.md match what you actually see on a run.

Official sources

1. Issues
2. License: MIT
3. Pan-Chera/Multi-Agent-CAD on GitHub
4. README
5. Releases