Claude is quickly running out of credits

I installed Rhino MCP Platform plugin and I asked Claude to write a basic code, something that i can usually do in ChatGPT for hours.

Claude quickly ran out of credits on my Pro plan, just after one iteration of the code.
Is it possible to use the MCP with ChatGPT instead of Claude?

Yes, you can connect to ChatGPT as well. Both seem to have their own strengths with Rhino. Are you on a lower Claude plan and did you run Fable 5 on max? That could likely burn through your 5 hour limit in one design.

Hi @C_Dav ,

I am on the basic Pro plan and Claude was set on Sonnet 5 medium. I asked it to do a few operations in Rhino, which it did by running python scripts. Afterwards i asked it to reconstruct all the operations it did in one final script and it ran out of credits. The whole test lasted less than 1 hour.

On the Rhino MCP Platform page i see that there is some implementation for OpenAI Codex but not for ChatGPT. So i am wandering, how can i make it work with ChatGPT Desktop the same as it works with Claude Desktop…

I believe I just followed the Codex instructions: OpenAI Codex – Rhino MCP Platform

How are you using Claude? Code, Desktop, web browser? Did you provide a structured prompt? If you let the LLM wander they will gladly eat up your tokens.

Something like:
Goal → Return Format → Examples → Constraints → Pitfalls → Acceptance test → Context

Hi @Japhy ,
I installed and used Claude Desktop. My prompts were short and concise, my goal was just to test.
I simply asked to check a geometry (a box) for filleted edges and unfillet them. Very simple.

Claude managed to do what i asked in Rhino. It took two attempts. Then i asked it to put all the workflow in a python script. It created one that didn’t work, then i asked for another iteration and I just ran out of credits.

The whole process took maybe 30 minutes… maybe less…
Usually with ChatGPT i can run endless iterations, attempt different strategies and try things for hours if necessary.

But I see that the install process for ChatGPT is not as straightforward as it is for Claude.
Can you simplify and document the installation steps for ChatGPT as they are for Claude?

Callum can tune those instructions up.

Interesting because i haven’t experienced running out of tokens in the pro plan very often, only when vibe coding an entire app from scratch.

Yes, it feels very strange to me to run out of credits that fast. It doesn’t seem normal. Here are my usage details.

oh, and i don’t neccesarly want to use codex. i want to use ChatGPT as it is.
For this RhinoMCP needs to become available as a regular ChatGPT plugin. no?

So a normal ChatGPT Desktop conversation should launch the local rhino-mcp-router and directly control Rhino.

One note. If you have many MCPs connected, any AI Agent will have a very high baseline token cost as it must load every tool for every MCP, and if it spins up sub agents, each of those will too, leading to a lot of token munching without any ROI.

Should be possible if it supports mcp agents, you’re on the money right here.

hi @CallumSykes ,
I don’t have many MCPs connected. I just use it as a regular user would. Therefore I cannot understand why I run out of tokens. If you have any other suggestions let me know.

Can you create a ChatGPT Desktop plugin like the one for Claude Desktop?

Let’s investigate!
RH-97791 ChatGPT Destkop plugin

thank you @CallumSykes ,
have a good weekend!

You too pal :slight_smile:

I asked Claude why i ran out of credits. Here’s the answer:

This session was genuinely heavy on usage, and I can point to the specific things that drove it:

1. Viewport screenshots (get_viewport_image)
Each call returned a full-resolution image (I called this repeatedly — after the spire, after the diagrid, after each fillet edit, plus a couple of failed selection-check attempts). Images are token-expensive to process compared to text, and I generated several of them.

2. Long, iterative debugging cycles
The two “increase fillet radius” tasks in particular took many run_python round-trips because I was probing the brep’s actual topology live (finding edges, checking adjacent faces, measuring curvature, retrying failed approaches) rather than getting it right in one shot. Each of those calls plus its full stdout/error output adds to the conversation’s token count, and every subsequent turn re-sends the growing conversation history.

3. Large tool outputs
Some scripts printed full edge/face dumps (e.g., the 29-edge listing after the first boolean union attempt) — verbose output that then sits in context for the rest of the session.

4. Selection-sync troubleshooting
The back-and-forth where I couldn’t detect your face selection involved several get_context and run_python calls that ultimately came up empty — wasted overhead.

5. Conversation length compounding
As the transcript summary at the top of this conversation shows, it was already compacted once — meaning the raw history was long enough that Anthropic’s system had to summarize earlier turns just to keep going. Every new message in a long conversation re-processes that accumulated context, so cost per turn creeps up over time even for short questions.

If you want to avoid this going forward: starting a fresh conversation per distinct task (e.g., one for the diagrid, a new one for fillet edits) keeps each session’s context smaller, and asking me to skip the viewport screenshot when you don’t need visual confirmation cuts a meaningful chunk of image tokens.