When Cursor IDE resumes a subagent, it does not keep using the original subagent’s model; it falls back to the parent agent’s model that invoked the subagent. For example: I used fable5 to launch a composer2.5 subagent; when fable5 later tries to resume that same subagent, the subagent’s model becomes fable5 instead of staying on composer2.5.
Steps to Reproduce
Open an agent chat and send:
“For every new subagent I explicitly set Grok 4.5 High Fast, but on resume the API doesn’t accept a model parameter, so the continued run falls back to my own model — Fable 5 1M High.” — Can you check whether this is actually true?
Hey there,
You’ve got the symptom right (resume drops the model you set and falls back to the parent’s), but one detail is off: the resume call does accept a model argument, and on the IDE it’s honored. The schema just suggests omitting it because a resumed subagent is meant to reuse its original model on its own, and that automatic reuse is what’s currently broken for local (in-IDE) subagents, so it falls through to the parent model. This is a known bug we’ve had reported before, and I’ve logged your report with it.
Two workarounds that both work today:
Re-pass the model on the resume call (e.g. Grok 4.5 High Fast). On the IDE the explicit choice is respected 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 or instruction, have it always specify the model on resume rather than avoid resume entirely. More on subagent model config here: Subagents.