CLI subagents changing model to composer 2.5 fast mode by itself

[Calvin_Ng]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

I always run prompts using the standard Composer 2.5 mode. However, starting today, Cursor began automatically spawning Composer 2.5 Fast subagents even though I never selected the Fast mode.

This behavior is extremely frustrating because Composer 2.5 Fast appears to consume usage at a significantly higher rate. Two relatively small tasks consumed approximately 30% (literally jumped from 40ish to 70ish) of my monthly allocation before I realized what was happening.

If you review my historical usage, you’ll see that virtually all of my prior activity has been performed using the standard Composer 2.5 mode, not the Fast variant. There was no intentional change in my workflow or model selection.

The following is extracted from the agent run asking specifically what models were used. Also validated with the log file, that somehow the tooling call recommended fast mode, from a regular mode parent agent.

The session where the orchestrator passed “model”: “composer-2.5-fast” on every Task call is:

cd37c164-bda5-4985-bafb-f2d194a8482c

Transcript path:

/Users/superx3man/.cursor/projects/Users-superx3man-Documents-Code-chefaio-app-ios/agent-transcripts/cd37c164-bda5-4985-bafb-f2d

194a8482c/cd37c164-bda5-4985-bafb-f2d194a8482c.jsonl

That session was also a plan-followup-orchestrator run on Agents/plans/task-definition-walkthrough-type-on-element.md. It has 14

Task invocations, each with “model”:“composer-2.5-fast”.

For comparison, this session (the one that merged PR #103) is:

484b0f4b-382c-4a71-a199-f0c651202392

-– same orchestrator + plan, but no model parameter on any Task call (parent-model inheritance).

There is one other session using an explicit model override, but a different slug: e81a2013-0fa3-463e-8a5d-dbb2d0adcb0b used

“model”:“composer-2-fast” for browser-agent-extract-components-sandbox-url-fetch.md (plan-execution-orchestrator, not

follow-up).

Steps to Reproduce

Select regular mode of composer 2.5, start workflow that would call subagents with no model configurations in header of the markdown.

Expected Behavior

All subagents should use composer 2.5 regular mode.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

2026.06.02-8c11d9f

Additional Information

This makes subagent unusable as it forces to use the more expensive yet same performance model.

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the detailed report. I can see the log showing "model":"composer-2.5-fast" on the Task calls, that really helps.

This is a known bug. In some cases, subagents resolve to the fast variant composer-2.5-fast instead of the regular composer-2.5 when the model isn’t explicitly set in the subagent frontmatter. I can reproduce it, and I’ve reported it internally. I can’t share a fix timeline yet.

As a temporary workaround, try explicitly setting the model in the subagent YAML frontmatter, for example model: inherit, so the subagent inherits the parent regular model instead of falling back to the default. It’s not guaranteed, but in your comparison it looks like sessions without an explicit fast param were using parent-model inheritance, so there’s a good chance this avoids the issue. Let me know if it helps.

If you want to look into usage that went to fast because of this, email [email protected] and they can check your account.

I’ll post in the thread once there’s an update on the fix.

[Gopher (Jayson)]

Hey, I also encountered this issue, but I’m on the IDE side.

I configured the sub-agent option in Cursor settings — I selected Composer 2.5, used edit mode, and turned off fast mode. However, when I use Opus 4.8 to do planning, the sub-agent still chooses Composer 2.5 - fast, which causes my usage to burn like crazy. As you said, this is a known issue. Is there any temporary workaround on the IDE side to make it correctly use Composer 2.5 as the sub-agent instead of fast mode?

[deanrie]

Hey, thanks for following up. Yep, it’s the same known bug, just on the IDE side. The subagent gets resolved to composer-2.5-fast even though the settings have regular Composer 2.5 selected with fast turned off. We can reproduce it and it’s been reported internally. I can’t share a fix timeline yet.

On the IDE side, there isn’t a reliable workaround right now since the issue is that the subagent model selection in settings isn’t being respected. If you’re using custom subagent definitions with YAML frontmatter, you can try explicitly setting model: inherit so the subagent inherits the parent model, but for built-in subagents when planning via Opus 4.8 this still isn’t guaranteed.

So we don’t mix your IDE case with the CLI report in this thread and can track it more easily, please start a separate thread for the IDE variant. Include a screenshot of your subagent settings and, if you have it, the Request ID from a session where the subagent went to fast.

For any usage that got billed as fast because of this, email [email protected] and they’ll check it on your account.

I’ll follow up as soon as we have an update on the fix.

[Gopher (Jayson)]

Bug: IDE Sub-agent (Composer 2.5) Forcibly Uses Fast Mode Despite User Setting

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug I configured the sub-agent option in Cursor settings — I selected Composer 2.5, used edit mode, and turned off fast mode. However, when I use Opus 4.8 to do planning, the sub-agent still chooses Composer 2.5 - fast, which causes my usage to burn like crazy. Steps to Reproduce Use Opus 4.8 making plan. Expected Behavior Sub-agent Use Composer 2.5 Screenshots / Screen Recordings [20260609-163852.jpg] Operating System Ma…

[Calvin_Ng]

hi dean, just a follow-up seems like even with ‘model: inherit’ cli specifically still routes to fast mode. it seems like this problem happens much more on cli. any other method I could leverage? anyway to just “turn off” fast mode completely on my account?

[deanrie]

Thanks for coming back with details. The fact that model: inherit on the CLI still ends up using fast mode is a useful signal, I added that to the report. Confirmed, this bug shows up much more aggressively on the CLI than in the IDE.

To answer your questions honestly:

• There isn’t a reliable workaround on the CLI right now. The root cause is how composer-2.5 gets resolved on the sub-agent side, and inherit doesn’t seem to override it every time.
• There’s also no account-level toggle to fully disable fast mode for your account right now. There’s an open feature request to disable fast for Composer 2.5 here: Select the fast mode or not on Composer 2.5 of Cloud Agent. If it’s relevant for you, please like it, it helps with prioritization.

This bug is known and reproducible, and I’ve reported it internally. Once there’s an update, I’ll reply in this thread.

[conradkoh]

Hi Dean,

Could you confirm if this solution given by Sam is correct?

[deanrie]

Hey, I’ll give an honest answer because there’s a nuance here.

The mechanism itself, explicitly setting the option via fast=false, is correct. But right now we only have a confirmed working case at the SDK level using params: [{ id: "fast", value: "false" }], you can see it in this thread: Cursor CLI calling `composer2-fast` despite always calling with `composer2. I can’t confirm that the bracket syntax composer-2.5[fast=false] in the .cursor/agents/ frontmatter reliably forces non-fast on the CLI. We don’t have confirmation for that yet. So it’s a workaround worth trying, but it’s not a guaranteed fix.

A couple clarifications:

• For inheriting the parent model, it’s more reliable to fully remove the model field from the frontmatter, instead of setting model: inherit, since inherit doesn’t always work on the CLI.
• As of today, the only stable confirmed path for non-fast is the SDK with fast: false. On the CLI, routing into fast still happens sometimes, and we’re tracking it.

Try the bracket variant on your setup and verify in the dashboard which model actually ran. If it still routes to composer-2.5-fast, send the Request ID from the parent chat three dots > Copy Request ID. Once there’s an update on a fix, I’ll post it in the thread.

[Calvin_Ng]

hi dean,

For inheriting the parent model, it’s more reliable to fully remove the model field from the frontmatter, instead of setting model: inherit, since inherit doesn’t always work on the CLI.

is this the latest and best option we have currently? it contradicts with what you suggested earlier in this thread which is setting model: inherit. Even though it’s not guaranteed, at least I would want to stick with a temporary solution that yield the best outcome.

[deanrie]

Hey, thanks for flagging this. We found a more reliable approach just a few days ago, so the earlier tip to use model: inherit is no longer relevant.

On the CLI, inherit doesn’t work consistently, and our latest tests confirmed that. The best option right now is to remove the model field from the frontmatter entirely. Without an explicit field, the subagent is more likely to pick up the parent model.

If it still falls back to composer-2.5-fast, please share the Request ID. In the CLI you can get it right in the session, type /copy-request-id.

This is a reproducible bug and it’s been reported internally. I’ll post an update in the thread once we have one.

[kulve]

[EDIT: I’m using the Cursor IDE even though this thread is actually about the CLI. Not sure if my finding applies also to the CLI.]

Some days/weeks ago the “model: composer-2.5” in the subagent’s md file picked the fast variant. I’m now using Cursor 3.7.27-1781057690 and tested the “composer-2.5[fast=false]” and that now correctly selects the non-fast variant. But I didn’t test if also the “model: composer-2.5” works now.

[deanrie]

Thanks for confirming, that’s a helpful signal. composer-2.5[fast=false] in bracket syntax is exactly the workaround we suggested above, and it’s good to see that on the IDE side in 3.7.27 it reliably picks the non-fast variant.

A couple quick notes:

• On CLI, this thread was originally about CLI, and fast routing still happens there more often than in the IDE. So your IDE result doesn’t guarantee the same on CLI, but it’s still worth trying the bracket variant there too.
• If you want to check whether model: composer-2.5 works without brackets, you can test it and then check the dashboard to see which model actually ran. Based on our data, without an explicit fast=false, it can still route to fast.

This bug is known and reproducible, I’ve reported it internally.

[Moumouls (Antoine Cormouls)]

@deanrie tried the bracket trick via CLI, but still pickup fast version for subagents, what is the ETA to fix this bug ?