AI Plugins for Rhino & Revit

Grasshopper is already parametric, not AI - but a rich layer of intelligent, AI-adjacent and genuinely-AI tools has grown on top of it, and it pays to keep them clearly sorted. The most established is optimisation: Galapagos, the built-in evolutionary solver, and the more capable Wallacei (multi-objective evolutionary optimisation with strong analytics) and Opossum (model-based / surrogate optimisation that finds good solutions in fewer runs). These are not machine learning in the modern sense - they are search algorithms - but they are how most designers first automate 'find me a good configuration of this parametric model.'

Then there is genuine machine learning: LunchBoxML brings regression, clustering and simple networks into Grasshopper; Owl, Dodo and Crow add neural-network and ML components. These are powerful but demand something most designers lack - your own dataset and a clear ML problem - so they stay niche. More immediately useful are the diffusion-render plugins: Veras (EvolveLAB) renders your Rhino or SketchUp viewport into an AI image in seconds, and the Ambrosinus toolkit wires Grasshopper to Stable Diffusion, DALL-E and chat models. Finally, the quietest revolution is LLM-assisted scripting: using ChatGPT or Claude to write GhPython or C# components, which turns Grasshopper scripting from a specialist skill into something far more approachable. Across all of these, remember what each really is - search, ML, image diffusion, or code generation - because that determines how hard you check it.

The reason optimisation dominates this side of the ecosystem is that Grasshopper users already think parametrically: they have a definition with sliders, and the natural next question is 'which slider values are best?' An evolutionary solver answers that by breeding and mutating candidate solutions across generations, while a surrogate-based one like Opossum builds a quick internal model of how the sliders affect the outcome and searches that. Neither is magic, and both can be led astray by a badly posed fitness function - the same lesson as generative planning, at the component level. The genuine-ML plugins are a different proposition: they let you learn a pattern from data, such as predicting a value from geometry, but in practice most studios have neither the labelled data nor the time, which is exactly why the diffusion and LLM tools - which need neither - have spread so much faster.

Revit's ecosystem leans more toward automation of documentation drudgery than toward generative form-making, which suits the phase of work it lives in. On the rendering and ideation front, Veras appears here too, turning a Revit view into an AI-rendered image for early presentation. On documentation, Glyph (EvolveLAB) automates annotation, dimensioning and sheet setup against rules, and DiRoots tools (SheetLink, ParaManager and others) automate data entry, parameter management and schedules - the repetitive work that eats hours. On early design, Revit connects outward to Forma and to TestFit, so conceptual studies flow back into the documentation model.

The deepest lever, though, is scripting: Dynamo (Revit's visual programming) and pyRevit (Python for Revit) let you automate almost anything, and LLMs have made writing that automation far more accessible - you can ask an assistant to draft a Dynamo Python node or a pyRevit script against the Revit API. The honest caveat, repeated on this side: much of what is marketed as 'AI in Revit' is rule-based automation, and both automation and LLM-written code need testing, because a script that runs on a thousand elements makes a thousand mistakes just as fast as a thousand corrections. Autodesk continues to fold more genuine AI (in Forma, in the cloud) into the stack, but on the documentation model itself, dependable automation is the workhorse - and it is a very good one.

The economics here are worth spelling out, because they explain why Revit's AI story looks so different from Rhino's. Revit is where documentation drudgery lives - the annotating, tagging, scheduling and data-entry that consume disproportionate fee for zero design value. Automation that reliably removes that work pays for itself immediately, which is why the mature, widely-adopted 'AI' tools on this side are really automation engines like Glyph and DiRoots rather than form generators. The frontier that is genuinely shifting is scripting accessibility: tasks that once required a dedicated computational-design specialist - batch-renaming, cross-checking parameters, exporting structured data for QA - are increasingly within reach of any competent Revit user willing to describe the task to an LLM and test the result. That democratisation is real, and it is arguably the most consequential AI change in day-to-day BIM work.

It helps to sort these plugins by what they do to your work. Some automate a task you would otherwise do by hand, and do it faithfully: laying out sheets, populating schedules, renaming and tagging elements, exporting data. Trust here is about correctness of rules and coverage of edge cases - verify a sample, then trust the batch. Some optimise: they search a parametric space for good configurations against your objectives. Trust here mirrors generative planning - they optimise what you encoded, so the result is only as good as your objectives and constraints.

Others reinterpret rather than automate, and this is the crucial distinction for renders. A diffusion-render plugin like Veras does not draw your model accurately; it uses your geometry as a prompt and generates a new, plausible image influenced by it. Materials, details and even proportions can drift. That is perfect for an early mood-render and dangerous for anything a client might mistake for the actual design. And some generate code - the LLM-scripting workflow - which produces text that looks like a working script and may contain subtle errors against the current API. The rule that ties these together: match your scrutiny to the category. Automation and optimisation you spot-check; reinterpretation you frame as illustration; generated code you test on a copy before it ever runs on the real model.

This four-way sort is more useful than the marketing label precisely because the failure modes are so different. An automation that is wrong fails loudly and consistently - it tags every door with the wrong parameter, which you catch on the first sheet. A reinterpretation that is wrong fails quietly and seductively - it produces a beautiful render of a building you did not design, which nobody catches until a client asks for the brass handrail the AI invented. And generated code fails unpredictably - it may work perfectly on your test elements and then choke on the one wall with an unusual join. Knowing which kind of failure a tool is prone to tells you exactly how to guard against it: verify coverage for automation, label intent for reinterpretation, and test edge cases for code. The plugin's name tells you none of this; its behaviour tells you all of it, so sort by behaviour every time.

The safe way to bring all this into a workflow is a single principle: the authored model stays clean and central; AI plugins sit at the edges and never cross into it unverified. Optimisers explore options outside the delivery model; diffusion renders are for presentation, not documentation; automation runs on the model but you review its output; LLM-written scripts get tested on a copy first. Version control - or at least disciplined save-copies - matters more once scripts can touch many elements at once, and it is worth keeping a note of which plugin produced what, because plugin updates and API changes break automations without warning.

A sane LLM-scripting loop, for either Dynamo/pyRevit or GhPython, looks like this:

1. Describe the task + the exact API objects to an LLM
2. Read the generated script - do you understand every line?
3. Run it on a COPY of the model, on a few elements first
4. Check results against what you expected, by hand
5. Only then run on the real model; commit a version

And a tiny illustration of the kind of code you would generate and then verify:

# pyRevit: tag every untagged door on the active view (review before trusting)
# an LLM can draft this; you confirm it against the current Revit API
# and run it on a copy first - never blind on the delivery model

Used this way, plugins compress the slow, low-value work - options search, renders, annotation, data entry, scripting - while the model you stamp remains something you authored and checked. That is the whole art: leverage at the edges, integrity at the centre.