Prohibition of Composer 2 for Sub-agents

Is there a proper way to disable Composer 2 for sub-agents so I don’t have to create such rules, some hacks and clutter my context with rules, because I’m absolutely dissatisfied with how Composer 2 works, how it doesn’t follow instructions and just writes crappy code that doesn’t follow the rules and repository design. This infuriates me. Why are there no system settings to disable such stupid models for sub-agents?

Hey, I get the frustration, this is a known confusing spot. Right now, built-in auto subagents, especially Explore and generalPurpose, can pick their own default model and often end up using Composer 2 or Composer 2 Fast no matter what model the parent agent is using. There isn’t a global toggle in the stable version yet.

What you can do right now instead of hacks in rules:

  1. Custom subagent with an explicit model. Create a file in .cursor/agents/*.md with YAML frontmatter and a clear model:. There’s a model picker in the UI after you generate the subagent. Running this subagent will always respect the selected model. More details: Subagents | Cursor Docs.
  2. subagentStart hook with permission: "deny" if you want to hard block spawning built-in subagents: Hooks | Cursor Docs.
  3. Omit model in Task or don’t pass it, then the subagent inherits the parent’s model. This doesn’t work for all built-in types, but it’s fine for custom ones and explicit calls via Task.

A separate Explore subagent model selector was added in Settings in 3.3, currently in the nightly channel. If you want it sooner, you can switch to nightly.

@deanrie For some reason, my nightly cursor isn’t showing any updates. I’ve also tried downloading it again, but it turned out to be the exact same version.

3.3 is already on the stable channel, so you don’t need to stay on nightly. That’s why the version isn’t changing. Switch to stable or re-download from here: Cursor · Download

After that, open Cursor Settings and search for subagent or explore. There’s a separate model picker for the Explore subagent.

If you can’t find it, send a screenshot of your settings and I’ll take a look.

This setting isn’t working; composer 2 still launches, and it’s throwing errors
If it’s not an explore agent but another one, it’s very stupid that the setting is only for a explore agent.

Composer 2 is a terrible model; it’s really frustrating that Cursor pushes it and doesn’t give us a choice! For the record, users can patch the IDE myself and change the Cursor code—which I’ve already had to do because of numerous bugs in the IDE—but I’m tired of constantly having to do this

Hey, thanks for the update. Let me clarify the setting behavior.

The picker in Settings from 3.3 controls only the Explore subagent. The subagent in your screenshot Verify auth redirect in browser is a different built-in one generalPurpose/Task, and the current picker doesn’t apply to it. So this isn’t a settings bug, it’s just the scope.

What can help right now:

  1. Custom subagent with an explicit model. Create a file in .cursor/agents/*.md with YAML frontmatter and model: claude-opus-4-7-thinking-xhigh or whatever you need. This kind of subagent ignores defaults, the parent will call that exact model. Docs: Subagents | Cursor Docs
  2. Max Mode on the parent agent. If you’re on the legacy request-based plan, without Max Mode the backend forces Composer 2 Fast for built-in subagents no matter what the parent model is and even if Model: Inherit is set. That’s by design for that plan type. Turning on Max Mode removes the force. If you’re on the new token-based pricing, this shouldn’t be an issue, so let me know.
  3. Hard-block built-in subagents via the subagentStart hook with permission: "deny". Docs: Hooks | Cursor Docs

About extending the picker to other built-in subagents, the feedback makes sense and it’s not the first report. I can’t share an ETA for more granular controls.

If you can share: a is Max Mode enabled on the parent agent in the screenshot, b are you on Pro legacy request-based or the new token-based plan, I can tell which option above fits you best.

I have two accounts, enterprise and personal with request-based pricing. And it doesn’t work for either one, stupid Cursor always launches it on Composer!
I understand that you are trying to limit early Cursor users so that they switch away from request-based plans because it’s not profitable for you, but why does Enterprise have the same limitations?

Thanks for the update. Let me split this into two cases, otherwise it gets confusing.

Personal, request-based legacy. This behavior is by design on this plan type. Built-in subagents Task and generalPurpose are forced onto Composer 2 Fast no matter what the parent model is, and Max Mode on the parent is required to disable that. This isn’t a bug on your side, it’s plan policy. Feedback is collected, there’s no ETA for softening this on the legacy plan.

Enterprise. This one is more interesting. On Enterprise, the built-in subagent should not be forced to Composer 2, and in some cases this is actually a bug. Allowlist and parameter restrictions are not applied to built-in subagent requests. To tie this to your case, I need:

  1. Is your Enterprise team on token-based pricing or legacy request-based?
  2. Was Max Mode enabled on the parent agent when you ran Verify auth redirect in browser?
  3. The Request ID for that request right top corner chat context menu > Copy Request ID.

What works right now both accounts:

  • A custom subagent with an explicit model in .cursor/agents/*.md, frontmatter model: claude-opus-4-7-thinking-xhigh or whatever you need ignores defaults. If you want to pin Composer 2.5 instead of Fast, use model: [composer-2.5]. Without brackets, the backend may silently resolve to fast. Docs: Subagents | Cursor Docs
  • Hard-block built-in subagents via the subagentStart hook with permission: "deny". Docs: Hooks | Cursor Docs

Send the answers to the three questions above and we’ll dig into the Enterprise case separately.

actually in the latest versions it seems like everything has started working normally, subagents have stopped calling composer models, although overall 2.5 is more or less suitable for programming. composer 2 was too bad. now everything is ok at least for me

Thanks for coming back with an update. If the subagents start switching to Composer 2 again on one of the accounts, drop the Request ID here and tell us which account it is, personal legacy or Enterprise, and we’ll take a look.

Also, I’ll pass your Composer 2.5 feedback on to the team. If you have specific cases where it fails, a separate thread with examples would really help.

alright, those were premature conclusions, nothing is working properly as usual. we have enterprise mode on a request based plan. also, cursor works disgustingly with subagents and constantly interrupts, it can’t complete the task! it delegates everything to agents and then doesn’t respond itself after the agent finishes the work. i end up calling gpt 5.5 but in the end, the composer does everything and not in the best way either. i have to constantly burn requests on requests to continue working!

req id bea820c5-b11c-439d-a198-3a554533b342


I have to switch to codex/claude code. Because it’s impossible to complete any complex task in cursor because of this crap!

Hey, thanks for coming back with more details and the Request ID. That really helps.

Let me split this into two parts so it’s not confusing.

  1. The parent agent sits idle after the subagent finishes. This is a known bug. The agent delegates work to a subagent, the subagent completes, but the parent doesn’t react to the completion and just hangs until you manually nudge it with proceed. From your screenshots, this looks exactly like that scenario. We’ve already reported this internally, but I can’t share an ETA for a fix yet. As a temporary workaround, for complex tasks it helps to rely less on auto delegation to built-in subagents. You can either use a custom subagent with an explicit model in .cursor/agents/*.md with frontmatter model: ..., or fully block built-in subagent spawning via the subagentStart hook with permission: "deny" https://cursor.com/docs/hooks. This makes it more likely the parent will finish the task itself without handing it off.

  2. Composer selection for built-in subagents is request-based. On the legacy request-based plan, built-in subagents Task and generalPurpose are forced onto Composer 2 Fast. That’s plan policy, not something broken on your side. For Enterprise, this should not happen, so it could be a bug. To tie this to your Request ID bea820c5-b11c-439d-a198-3a554533b342, can you confirm:

  • What exact Cursor version you’re on right now
  • Whether Max Mode was enabled on the parent agent for that run

If you can, please start a separate thread specifically for parent not continuing after a subagent with this Request ID and the version. That way I can link it cleanly to the investigation without mixing it with the Composer forcing topic.

I’ll pass your feedback about Composer 2.5 quality to the team. If you’ve got specific cases where it fails, examples would help a lot.


The agent tells me straight up that it won’t run these agents and then immediately runs them… I’m on the enterprise plan, how much longer do I have to wait for this to be fixed

req id 99dba20d-02a9-4b05-94e9-50b9253901ed

Version: 3.10.20
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0