While using Grok 4.5 High during debugging, the model was switched to Claude Sonnet 5 Thinking High and used 4M worth of tokens, which was not planned from my end…
Steps to Reproduce
Select debug agent (/agent)
Select Grok 4.5 High
Run debug
Expected Behavior
Debug completed with selected model (Grok 4.5) only
Running into model switches to, it’s a thing. Don’t know how to describe it because when it happens its in more complex work that’s harder to describe. I’m blaming it on a problem with our hooks or their triggers. They have always been a bit flakey and or misunderstood but I run into similar random behaviors with glm 5.2 so I don’t think its model but harness tuning for new models, maybe the way they set or trigger hooks. All pure speculation,just feel.
Just started noticing this with 3.10.20 - I have it set to Grok 4.5 high and I have my explore subagent set to inherit but it very often will switch to “GPT 5.6 Sol Medium” on the rare occasion it correctly stays as Grok 4.5, somehow it seems to always pick Sol Medium when it goes rogue. So far it’s wasted at least 11% of my API pool, would be great if it got fixed while I still have some left… Hopefully I can get that refunded eventually but I can’t be bothered with that kind of thing usually.
I explicitly configured Grok as my subagent model, but Cursor spawned a subagent using Claude Sonnet instead. This was not an automatic model choice I consented to, and it consumed my usage allocation unexpectedly.
Please investigate why the user-selected subagent model is being overridden. The configured model should be treated as a hard constraint, not a preference.
I have also contacted billing support and requested restoration of the unintended usage.
Hey, thanks for the report and the screenshot. It actually clears up what happened. This isn’t a random model switch mid-run.
In Multitask/debug mode, the main agent you’re using Grok 4.5 High can spawn Task subagents. In your screenshot, that’s the Strip debug instrumentation card. A subagent can run on a different model than your main one, and in this case the parent agent picked Sonnet 5 High for it. The Sonnet tokens are real subagent work, not a billing mistake.
One important detail. The Explore subagent model setting only controls the built-in Explore subagent, not every Task subagent that the agent launches on its own. So even if you picked Grok, a subagent can still end up on another model.
This is known behavior and it’s on our radar. I can’t share a timeline for a change yet.
What helps right now:
Hide or disable expensive models like Sonnet 5 in the model picker. Then the parent agent can’t choose them for subagents.
Ask directly in your prompt to use a cheaper model for subagents, for example use Composer 2.5 for subagents.
About refunds for the usage spent. That’s handled by the team at [email protected], email them and they’ll check your account.
So was this an operator error on my end or a bug? I couldn’t find any information about multitask in the doc.
I sent an email to see if I can get back my API usage, and I was told API usage is covered in my plan and doesn’t meet the criteria, and they won’t be giving back the API usage.
Hey, I’ll be direct: this isn’t on your side. What you saw is known behavior, not a random model switch in the middle of a run.
Quick version of what’s happening: in Multitask or Debug mode, the main agent (yours is Grok 4.5 High) can spin up Task subagents, and the parent agent can sometimes assign a model to them. That assigned model overrides both your main model and the subagent model setting. The Explore subagent model setting only controls the built-in Explore subagent, not every Task subagent. So even if you picked Grok, a subagent can still end up on Sonnet 5 High. This is on our radar, but I can’t share a timeline for changes yet.
You’re also right about the docs. This behavior isn’t described right now. Debug Mode is documented Debug Mode | Cursor Docs and subagents are documented Subagents | Cursor Docs but there’s nothing yet about how the parent agent picks a model for Task subagents.
To avoid this happening again:
Hide or disable expensive models (Sonnet 5, etc.) in the model picker so the parent can’t pick them for subagents.
Ask directly in your prompt to use a cheaper model for subagents, like use Composer 2.5 for subagents.
On the usage refund, that’s handled by [email protected]. Since they already replied, I can’t influence that decision from the forum. Let me know if the workarounds don’t help.
Thanks for that info. I honestly wished it was my fault for not being thorough with documents,niw I’m reliefed and concerned at the same time. There are other users reporting the same issue as mine and I don’t think they are aware of this. Could you guys push a PSA out to the community at lesst for everyone’s awareness?
Glad it’s clearer now, and yep, you’re right that other users are hitting the same thing.
On the PSA: I won’t promise a full community blast, but I’ve already raised the docs gap internally. The model selection behavior for Task subagents isn’t documented anywhere right now, and we should fix that in Subagents | Cursor Docs and Debug Mode | Cursor Docs. Also, this thread stays open and public, so it works as a single place for anyone who googles the same symptom.
The behavior is on our radar, but I can’t share a timeline for changes yet. For now, the best way to be safe is what we mentioned earlier in the thread:
Hide or disable expensive models like Sonnet 5 in the model picker so the parent can’t pick them for subagents.
In your prompt, explicitly ask for a cheap model for subagents, like “use Composer 2.5 for subagents”.
If you notice that even with those models disabled the subagent still goes to Sonnet, send the Request ID and I’ll take a look.
