When a model spawns subagents, it doesn’t respect settings that hardcode the subagent model. In my case, I have explicitly set composer-2.5 (without fast mode toggled), but every time a subagent is spawned, it is powered by composer-2.5-fast which burns through my quota, and I have no control over this.
Steps to Reproduce
Open Cursor → Settings → Agents → Subagents → Set explore subagent to composer-2.5 and ensure that the fast toggle is OFF in edit.
Start any task in a codebase (pick GPT 5.5) and watch it launch subagents with composer-2.5-fast
Expected Behavior
The explicitly set subagent model should be used with the exact configuration that the user wants and shouldn’t be modified behind the scenes.
Hey, thanks for the detailed report. This is a known bug. When you pick composer-2.5 for the explore sub-agent in Settings, the backend still applies the default fast=true, so the sub-agent ends up as composer-2.5-fast. It’s been reported internally, but I can’t share a fix timeline yet.
If you define sub-agents via frontmatter in .cursor/agents or .claude/agents, there’s a workaround. Explicitly set the variant using bracket syntax:
model: composer-2.5[fast=false]
This resolution path respects the parameter. For the built-in explore picker in Settings, there isn’t a clean workaround right now.
I’ll post here as soon as there’s an update on the fix.
Hey, no update on the fix yet. This is still a known bug where a subagent doesn’t respect the selected model variant and switches to fast or picks the wrong model. I can’t share an ETA. Once I have one, I’ll reply in the thread.
About .cursor/agents. This folder isn’t created by default, you need to create it manually. Both project-level .cursor/agents/ in the repo root and user-level ~/.cursor/agents/ work. Inside, put one .md file per subagent with YAML frontmatter. Example:
Key point. Control the variant using bracket syntax in the model field:
model: composer-2.5[fast=false] uses the normal non-fast variant.
model: composer-2.5[] or model: [composer-2.5] also forces the base variant.
model: composer-2.5 without brackets can silently fall back to fast on the backend.
This syntax also works for other model params, for example claude-opus-4-8[effort=high]. It’s not documented yet, but it works. Note: this works in IDE frontmatter, but the CLI --model flag doesn’t parse bracket params yet. In CLI you need to pass the exact slug, like claude-opus-4-8-thinking-high.
Frontmatter fields: name, description, model, plus optional readonly, is_background.
A few notes:
This workaround only works for custom subagents defined via frontmatter.
For the built-in Explore subagent, in Settings 3.3+ there’s a separate dropdown Explore subagent model where you can pick a model or Inherit. But composer fast vs non-fast is currently bugged. Even if you select composer-2.5 with fast disabled, the backend may still switch to fast. For other built-in types like generalPurpose, there’s no separate picker.
If you’re on the legacy request-based plan, built-in subagents are forced to Composer Fast no matter what you pick. That’s plan policy, not a bug. Turning on Max Mode on the parent agent removes this limitation.
If you want to block built-in subagents entirely so they don’t burn tokens, use the subagentStart hook with permission: "deny": Hooks | Cursor Docs. Note: for this hook, "ask" isn’t supported and is treated as "deny".
One more thing. The model in frontmatter can sometimes be ignored and the subagent inherits the parent model. That’s a separate known bug. If you see that even with an explicit bracketed model, send the Request ID right top corner of the chat > Copy Request ID and your Cursor version, and we can dig in.
i also got this issue, and config the hooks in subagentStart as your mentioned.
However, this seem only affect the ui, which is showing Couldn't startand hook log, but the agent still running. Request ID: cf6bbf09-aea4-46c0-a6a9-d68ffd8cfd19
Hey, thanks for the report. What you’re describing: subagentStart returns permission: "deny", the UI shows “Couldn’t start” and you can see the hook log, but the subagent still runs anyway (edits MILESTONE-CONTEXT.md, status “Working”). That’s a separate bug from what’s being discussed in this thread (that one is about model selection or the fast option).
Could you please start a separate thread in Bug Reports so we don’t mix them up. Please add:
Both screenshots you already attached.
Your hooks.json (the subagentStart block), with any sensitive data removed.
Your Cursor version Help > About.
Can you confirm: is “1 Working - Recheck lifecycle blockers” the same subagent that got the deny, or did the agent spawn another one after the deny or keep working on the task itself?
What type of subagent is it, built-in explore or a custom one from .cursor/agents?
Request ID: cf6bbf09-aea4-46c0-a6a9-d68ffd8cfd19 (we already have it, just paste it again in the new thread).
Drop the link to the new thread here once you’ve created it, and we’ll pick it up and try to reproduce.
Hey, thanks for the screenshots. I see what’s going on. The Explore subagent in Settings is set to GPT-5.6 Luna Medium Fast, but the explore task actually ran on Gemini 3 Flash.
The built-in Explore picker in Settings not always respecting the selected model is a known bug. I can’t share an ETA for a fix yet. But in your case it’s not just a fast variant of the same model, it’s a totally different family Luna to Gemini, so this might be a separate issue from what we discussed earlier in the thread.
To figure out if this is the same bug or something new, please share:
The Request ID for that run right top corner of the chat > Copy Request ID
Your Cursor version Help > About
Which model the parent agent was set to at the time
Once there’s an update on the fix, I’ll post it in the thread.
Hopefully it was from machine: Version: 3.13.6 (Universal) my other machine is on Nightly, which updates frequently (job was on the 16/17th of July). It was a cloud agent, so not sure if that helps (Is the snapshot ID useful?)
Hilarious that it decided to start looking into other stuff… I wonder if Sol had taken over by this point, as I’ve never seen Composer do this. After this point I switched the main agent to Grok 4.5 High to continue
This was on a linux box, using the official AppImage and a cloud agent:
@deanrie should I be contacting support about this? It looks like 56M tokens were used on Sol (difficult to determine exactly what for) but this bug has taken ~30% of my plan’s API usage? The first 2/3 events here being Sol makes sense, the later ones though…
Thanks for the details and screenshots. I can see the events table for gpt-5.6-sol-high and the chat where you directly told the agent not to run Explore via Sol, but it still switched to Sol.
What you’re seeing is different from the original report in this thread. The OP had composer-2.5 switching to the fast variant of the same model. In your case, the subagent is picking a completely different model family (Sol or Gemini instead of Composer). That’s also a known issue. The built-in Explore subagent doesn’t always respect the selected model and can switch to another one. We’re tracking it, but I can’t share an ETA yet. I’ll post an update when I have one.
I’ve noted the Request ID bc-038b326f-fd03-4264-aa71-4bedc4bbd891, version 3.14.7, and that this was a cloud agent. That’s exactly what we need, thanks.
Quick thread hygiene request. Since your symptom (different model family) is different from the original one, please start a separate thread in Bug Reports for built-in Explore runs a different model family and drop the link here. Include both screenshots, the Request ID above, the version, and the parent model (Sol High → Composer 2.5 Fast). That way we won’t mix two different cases and we can track yours more accurately.
About the burned quota and should you contact support. Yes, for usage questions it’s best to email [email protected].
Include the same Request ID there so they can check your account details.
