One Wall, Five Ways to Build It

Cover image: a Dieste-style brick wall in Rhino, with Grasshopper and Claude Code visible during earlier modeling tests on September 29, 2026.

We gave agents access to Rhino through MCP and asked them to build a curved brick wall. The cheapest successful approach used just one MCP tool: Run Python.

With Sonnet, that approach averaged $0.16 and 36 seconds per run, passing all three trials. Building through individual Grasshopper component calls averaged $1.41 on the same model—roughly nine times the cost.

The comparison also showed something more useful than a headline cost difference: agents could produce an editable Grasshopper definition with substantially fewer exchanges when they constructed larger portions of it at once.

The test

The wall was inspired by Dieste’s church at Atlántida: a ruled surface between a straight base and a sine curve at the crown, clad in running-bond brick. Our test model had 87 courses and roughly 3,350 bricks.

We compared five construction methods:

1. Rhino commands.
2. Direct Python using RhinoCommon, without Grasshopper.
3. Grasshopper assembled component by component.
4. Grasshopper constructed through Python using its SDK.
5. Grasshopper constructed from a complete graph description.

Every method had to produce the same baked wall, organized into layers for the surface, control curves, courses, brick centroids, and bricks. The Grasshopper methods also had to leave an editable definition with nine named sliders.

That extra deliverable matters. Direct Python produced the geometry; Grasshopper also provided controls for changing it afterward.

The construction method was prescribed in each brief and enforced through the available tools. Earlier Rhino tests had prompted the question: agents repeatedly used Python for ordinary geometry tasks without being assigned that method.

Results

Figures are means per run. Each combination had three trials, except Sonnet’s Grasshopper-through-Python approach, which had two.

Method	Model	Cost	Time	Turns	Passed
Direct Python	Opus	$0.72	83 s	6	1/3
Direct Python	Sonnet	$0.16	36 s	3	3/3
Grasshopper, component by component	Opus	$1.81	317 s	75	3/3
Grasshopper, component by component	Sonnet	$1.41	402 s	110	2/3
Grasshopper built through Python	Opus	$1.29	247 s	10	2/3
Grasshopper built through Python	Sonnet	$1.02	627 s	19	2/2
Grasshopper, complete graph description	Opus	$1.05	232 s	18	3/3
Grasshopper, complete graph description	Sonnet	$1.35	473 s	52	3/3

Passing required both the deterministic geometry checks and compliance with the assigned construction method.

The command-based approach never reached graded runs. Smoke attempts stalled at dialogs or prompts the agent couldn’t see. The furthest reached 30 minutes without placing any bricks.

Larger operations reduced the exchanges

The clearest comparison was within Opus: constructing Grasshopper from a complete graph description reduced mean turns from 75 to 18 and cost from $1.81 to $1.05. Both approaches passed all three trials.

Sonnet showed the same direction, but a smaller cost reduction: $1.41 to $1.35. Its graph-description runs required more component lookups and revisions. Sending a complete graph still depended on finding the right components and correcting mistakes.

The component-by-component approaches accumulated an average of 1.34 million input tokens per run on Opus and 2.32 million on Sonnet. More exchanges meant more repeated context.

Fewer turns didn’t always mean less elapsed time. Sonnet’s Grasshopper-through-Python approach used fewer turns than component-by-component construction, but took longer.

Efficient construction still needs checking

Sonnet passed all three direct-Python trials. Opus passed only one. Its two failures involved the running bond and brick dimensions.

A complete script can efficiently produce a model that still fails the brief.

File size didn’t distinguish the methods either. Every run stored the bricks as full Breps, producing geometry-only Rhino files of roughly 42–49 MB. The agents didn’t choose the more compact extrusion or block-instance representations.

As in our Arch Studio 1.5 evaluation, the useful conclusion is tied to the task and the checks. Here, larger operations reduced construction overhead; they didn’t eliminate geometric errors.

What this means for tooling

An agent can produce an editable Grasshopper definition without assembling it through dozens of individual tool calls. We can preserve the controls a designer needs while letting the agent construct the definition through code or a graph description.

MCP supported every approach in this comparison. In the cheapest successful runs, it provided a way to execute Python inside Rhino.

That makes tool design part of the working environment around the model—the agent harness. The size of an operation, the information returned, and the checks available afterward all affect how the agent completes the task.

These findings are informing the Rhino skills we’re developing for Arch Studio: support larger construction operations, preserve useful editing controls, and check the resulting geometry.

Limits and reproducibility

This was a small evaluation of one regular, repetitive wall: 23 graded runs across two models and four methods, plus separate command-based smoke attempts.

We used Rhino 8.35 on Mac, McNeel’s Rhino MCP plugin 0.3.0, and Claude Code with Opus 5.5 and Sonnet 5.5. No Arch Studio skill was used in the comparison, although the operator’s existing Claude configuration was loaded.

The Grasshopper approaches had an additional deliverable, so their costs are not directly interchangeable with producing baked geometry alone. The results also don’t establish how these methods perform on irregular geometry, unfamiliar components, Windows, or other model families.

The briefs, harness, graders, and recorded results remain in our local evaluation records. This article reports those results; it does not provide a public reproduction package.

The next question is what the same wall reveals about the knowledge agents are missing.