Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
When working with GPT-5.6-Sol, the agent correctly notes that it has completed the task assigned to the Grok 4.5 sub-agent. However, it proceeds to operate independently based on this, consuming a massive number of tokens.
Steps to Reproduce
Scheduled long-running session with delegation of plan steps to sub-agents.
Screenshots / Screen Recordings
Operating System
Windows 10/11
Version Information
IDE ver.: 3.12.17
For AI issues: which model did you use?
GPT-5.6-Sol, effort: High
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor
With long-running agents, they start completely ignoring the original plan and arbitrarily selecting expensive models, even though the rules explicitly forbid this.
Hey there!
You’ve diagnosed this correctly. When a subagent is resumed, it’s meant to keep the model it was originally spawned with (Grok 4.5 in your case), but for local (in-IDE) subagents that original model isn’t being carried over on resume, so the run falls back to the parent agent’s model (GPT-5.6-Sol here). That’s why the plan step still reads as Grok while a more expensive model actually does the work and burns through tokens. This is a known bug we’ve had reported before, and I’ve logged your report with it.
One clarification: the main agent continuing to coordinate and plan after a subagent finishes is expected behavior. The actual defect is just that the resumed subagent work ran on the parent’s model instead of Grok.
Two workarounds that both work today:
- Re-pass the model explicitly on every resume (e.g. Grok 4.5). On the IDE an explicit model argument is honored and overrides the parent fallback.
- Skip resume and spawn a fresh subagent with the explicit model instead. You lose the resumed context, but the model stays correct.
If you’re driving this from a rule, the key is to have it always specify the model on resume rather than relying on the subagent to remember it. More on subagent model config here: Subagents.
I’ll update here once a fix lands.
I’ll add to your solution: the workflow stabilizes if, during the planning stage, you explicitly specify the need to break down large tasks into smaller ones for sub-agents.
