I started this request using Opus 4.6 Thinking, and I expect the task to be completed with Opus 4.6 Thinking. However, I can see the subtask starts under “Composer 1.5.” It isn’t doing what I’m asking: I tell it to use the browser, and it runs “fetch” and “search” actions instead. Either it doesn’t understand the distinction, or the browser feature is malfunctioning
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
Hey, thanks for the report. There are actually two separate things here, so I’ll cover both.
About Composer 1.5 in subagents: this is expected behavior. The built-in subagents (Explore, Browser, Bash) use faster models by default for efficiency. The idea is that the subagent does the “draft” work (search, navigation, parsing), then returns the result to the main agent, which runs on the model you selected (Opus 4.6). More details here: Subagents | Cursor Docs
If you want subagents to use a specific model too, you can create a custom subagent with model: opus-4.6-thinking in .cursor/agents/. The format docs are in the same place.
About the Browser MCP error: the screenshot shows “Browser MCP tools returned an error - possible configuration or permission issue”. That’s a separate issue. Can you share the Request ID from the chat where it happened? Also check in Cursor Settings > Tools & MCP that the Browser tool is enabled.
btw the “/create-subagent Help me create this subagent for Cursor:” doesn’t work , cursor only knows about skills and had to read the change logs and the docs to learn how to make them
Yep, you found the right note in the docs. On request-based plans, subagents use Composer by default unless Max Mode is enabled. This isn’t a downgrade, it’s just how billing works on request-based plans.
Two options if you want subagents to use the selected model:
Enable Max Mode in the chat settings
Switch to a usage-based plan (then the model is used by default without extra toggles)
The error “MCP file system options are required for CallMcpTool” is a known bug, the team is aware.
/create-subagent
I can see the screenshot, the agent is trying to create skills instead of subagents. This is a known issue with /create-subagent. For now, the workaround is to create the file manually in .cursor/agents/:
---
name: my-agent
description: Description here
model: inherit
---
Your agent prompt here
You’re saying it’s “not a downgrade,” but from the user’s perspective it is.
I picked “opus-4.6-thinking” expecting the actual analysis and decision-making to run on that model. After the update, the UI shows subagents (Explore/Browser/etc.) running on “Composer 1.5” by default on request-based plans. That materially changes behavior and quality, because the subagent is the component that decides what to search, what to click, what to extract, and how to interpret results. If that part runs on a weaker model, the overall outcome is worse even if the parent agent is still Opus.
So “the main agent is still Opus” doesn’t negate the downgrade in practice—because the critical work is happening inside the subagent.
And “use Max Mode” isn’t a neutral workaround; it changes the cost structure dramatically. The end result is: to get the same capability I previously had when selecting Opus, I’m now being pushed into a more expensive mode.
I hear you. That’s a valid argument. If a subagent is making key decisions like what to search for, what to extract, and how to interpret it, then the subagent’s model directly affects the result. That’s a fair point.
I won’t repeat the “it’s by design” thing. You already know the options like Max Mode and the usage-based plan. The main point is that the current behavior on request-based plans is a limitation, and the team knows it’s inconvenient. A few users have reported the same thing. There’s no ETA, but your feedback helps us prioritize.
On Browser MCP and /create-subagent, both are logged. Let me know if anything else comes up.
if subtasks really do downgrade the model, there should at least be a log showing which model ran. the same opacity problem exists with Auto mode. you can’t tell what’s actually being used without guessing from output quality
Transparency, knowing exactly which model ran in each sub-task step, is already being worked on by the team. Right now the UI shows “Composer 1.5” in the sub-task title, but I agree that a full per-step model log would be more useful.
On the option to choose the sub-agent model and have separate billing for it, that’s a fair request. Today there are two paths: Max Mode, or custom sub-agents with a specific model: in .cursor/agents/. Neither is perfect for your use case, but your report helps us prioritize a better solution.
Is there some way to know why Cursor started to use the Composer 1.5 model today? Is it a rollout thing? When is it deciding to fire up Composer and when it is handling the whole thing using the requested agent? This kind of messes up the budgeting one would have for the tasks. One request is now always 3.
@deanrie How does Cursor decide when to activate Composer instead of handling the request entirely with the selected agent? This makes cost planning difficult, since Composer itself counts as two requests, and Opus appears to spawn two sub-agents. In practice, this means a single request can turn into five or more requests if additional sub-agents are created.?
The agent spawns subagents automatically based on the task. There’s no toggle to force it on or off. The three built-in subagents (Explore, Browser, Bash) kick in when the agent thinks it needs to search the codebase, run shell commands, or use a browser. More complex tasks that need several of these actions will naturally spawn more subagents.
On request-based plans, each subagent counts as a separate request and runs on Composer by default. So yes, one prompt can turn into 3 to 5+ requests, depending on how many subagents the agent launches. This is covered earlier in the thread and in the subagents docs.
Two ways to control this:
Max Mode: subagents will use your selected model instead of Composer, but the cost goes up.
Usage-based plan: billing is per token, not per request, so subagent spawning doesn’t cause the same budgeting issue.
We’ve noted the feedback about cost transparency and better control over subagent behavior. Several users have raised this, and the team is aware. No ETA yet, but your reports help us prioritize.
IMHO, Cursor is just doing EVERYTHING to annoy request-based plan users as a means to push them to other plans. And as a matter of fact, Cursor worked very well with Opus (2x requests) before this sub-agent (based on Composer 1.5) - I don’t need and don’t want that “feature”. On top of that, now every Composer 1.5 sub-agent counts as 2 requests with just a couple of hundreds K tokens - this is ridiculous and unacceptable.
Edit: the “community” considered my comment as inappropriate, ok, I edited off one spicy word… But, facts are facts…
To those interested, you may explicitly instruct the main agent to never launch sub-agents using something like “Do NOT launch sub-agents for the task, just finish your task within the main agent.” - at least for now with Opus, I can get somewhat I expected - no Composer 1.5.
Yeah I just added a prompt rule to never use subagents. Will turn it on again if settings are added to easily control what model is used.
I like subagents but I want to choose my model, usually I want the best model available regardless of cost. And when cost matters, Composer 1.5 is not even cheap, it costs more than frontier models like Gemini Pro 3.1. Ridiculous.
Please never assume you know what model I want to use.
