I am trying to build a Mesh Analyzer in Grasshopper using the new Rhino 8 Python 3 Script Editor. I am using Rhino 8.15. To speed up the process, I tasked Google’s Gemini AI with writing the script for me.
However, the code provided by Gemini completely fails, throwing a runtime error and turning the Grasshopper component bright red. It seems the AI heavily struggles with the new .NET/CPython 3 environment and keeps mixing it up with legacy IronPython (Rhino 7) workflows.
Before I give up on using AI for this entirely, I want to ask a broader question to the community:
Has anyone here successfully used Gemini or other AI assistants like Claude or ChatGPT, Copilot to generate working, error-free Python 3 scripts for Rhino 8 from scratch? Which AI model is actually capable of handling the Script Editor and its data binding without crashing the component?
I’ve used Claude more than once, but of course there are always errors in the code. It’s just that with Claude, it seems to me, they’re not that difficult to fix, and once you’ve got a relatively stable version, it’s much easier to continue.
I have managed this using the RhinoMCP as it can open Rhino, load the GH plugin and debug it and keep trying. You’ll want to use a later version of Rhino 8 though, 8.15 is old
I already have quite a small collection of scripts done with ChatGPT.
My problem is now about how to organize them, move some from one category to another - the UI of grasshopper is quite limited when it comes to rearranging components and modifying their properties.
@Balazs , if the script gives you an error, copy the error from the terminal to your AI and it will attempt to solve it or give you more information about it.
Also useful is to split a big problem into smaller parts.
You can connect claude to run Rhino commands, write python scripts and create Grasshopper definitions (like the rhino mcp but a little simpler to set up), you get a script browser for all generated Rhino scripts that you can share, it knows how to create HTML UI and eto forms and there are some very cheap agents on there that are good for experimentation and playing around.
I use Grok. I’m able to ‘one-shot’ relatively simple stuff… sometimes… and usually debugging is quite simple. I’m just getting back into scripting so it took me awhile to remember things like type hints.
I’m sure if I did something more complex I would have to get into some real debugging. But it’s likely that I would save significant time still - the debugging ends up being about as much as if I had written the code myself. But now the code is generated in seconds/minutes.
It gets a few things wrong repeatedly which is annoying and seemingly impossible to avoid. The GetOneObject / GetObject "Result is always wrong but this is more to do with scripting outside GH. I’m sure I’ll encounter similar things but you just tell it and it usually sorts it out.
The legacy issues you’re speaking of are either due to using a really crappy AI version (free?). I don’t want to say that it might be your prompts because that’s victim blaming ;-). If you’re half decent at Python you should be able to steer the AI to Python 3 in a single prompt. I haven’t used Claude for a year but it was pretty bad (even the paid version) and would even revert back; remember though this was one year ago - paid but back when it was monthly not token based. Grok however gets it right away. Some of the issues above might be due to the older versions of RhinoCommon but given that the documentation is patchy and tons of code on Github doesn’t even work, it’s amazing it’s able to get as much as it does.
I think the model is only part of the issue here. A generic AI chat usually cannot see which Rhino/Python runtime is active, the component’s actual input types and values, its current errors, or whether the output geometry is correct, so it can easily fall back to old IronPython examples.
I developed Ghost Writer for this closed-loop workflow. It opens a C# or Python Grasshopper component in an external IDE, provides environment-specific agent instructions, and exposes current inputs, runtime messages, and output previews so the agent can edit, save, inspect the result, and iterate. It removes much of the Rhino 7/Rhino 8 context mismatch described here.
I did - once, about 2 months ago. But it was quite a struggle, and I’ve been told the way I got it to work was not the way to do it. This is the thread in which I explained how I did it:
Using the Rhino MCP so Claude can talk to Rhino and grasshopper directly. Claude did a very good job cleaning up a super sloppy script I wrote, identifying functional groups with in it and organizing the canvas. It’s also successfully added functionality, both with conventional components, successfully using plugging, and writing python and wiring it all up. It’s very similar to other vibe coding experiences I’ve had. It works best when you have a clear idea of the approach you want to use and you give it clear instructions, works great at debugging together. Using the Opus 5 model on the $20 dollar Claude plan. It does start to get usage hungry as the chat gets longer, but generally very impressed.
@ShynnSup ,
You write the code in a Python or C grasshopper component.
Then you turn your component into a User Object.
(select it and go to File - Create User Object)
Additionally you can internalize data before creating the User Object.
Kea can do this and companies like KPF use Kea to create AI-generated script components as building blocks (which aren’t as granular in scope and as spaghetti-inducing as most standard GH components)
Also Kea has a mini-agent-like mode where it doesn’t just generate code but keeps fixing bugs until it compiles.
