Subagent model `composer-2.5` drops `fast=false` and runs Composer 2.5 Fast

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Product: Cursor Desktop 3.24.9 (Windows)
When: 2026-10-09, about 14:17 local (18:17 UTC)
Account behavior: Plan mode on Grok 4.7 High spawned two Explore subagents. The Task calls passed model: "composer-2.5". The subagent chips ran as Composer 2.5 Fast.

Actual

The parent turn stayed Grok 4.7 with fast=false. Both Explore children were billed/shown as Composer 2.5 Fast.

The Task arguments were:

  • subagent_type: explore
  • model: composer-2.5

They were not composer-2.5-fast.

Request IDs

Parent composer e26f1192-4350-44d9-8b3a-ed61dbb0d2e6
Parent generation 62b8a1d8-0a67-4507-9b75-fef98c89e9a2
Model grok-4.7

Explore subagent 8a0ec63b-9ae6-4e66-bb45-dac45b23109b
Generation b1919ac9-6597-4912-8361-d07ccc48bacc
Logged modelId: composer-2.5

Explore subagent 6a481c72-1882-46b2-a4c0-7ec77b499118
Generation 839bf41f-b4e4-4aca-963d-ee16e8f4217c
Logged modelId: composer-2.5

Agent Host log (Selected Agent Host turn runtime, runtime connect):

14:17:07 conversationId=e26f1192-4350-44d9-8b3a-ed61dbb0d2e6 generationUUID=62b8a1d8-0a67-4507-9b75-fef98c89e9a2 modelId=grok-4.7
14:17:24 conversationId=8a0ec63b-9ae6-4e66-bb45-dac45b23109b generationUUID=b1919ac9-6597-4912-8361-d07ccc48bacc modelId=composer-2.5
14:17:27 conversationId=6a481c72-1882-46b2-a4c0-7ec77b499118 generationUUID=839bf41f-b4e4-4aca-963d-ee16e8f4217c modelId=composer-2.5

modelId is composer-2.5 for both Fast and standard. The variant is the fast parameter, which this log line does not record. Please check the child request parameters for those two generation UUIDs.

Settings that should have forced standard

Saved model parameters:

  • composer-2.5: fast=false (saved 2026-07-27)
  • grok-4.7: fast=false, reasoning effort high, context 256k

Explore subagent override (cursor/subagentModelOverrides):

{
  "explore": {
    "mode": "model",
    "modelConfig": {
      "modelName": "composer-2.5",
      "maxMode": false,
      "selectedModels": [
        {
          "modelId": "composer-2.5",
          "parameters": [{ "id": "fast", "value": "false" }]
        }
      ]
    }
  }
}

The non-fast choice is still stored. It is not what ran.

Catalog default that filled the gap

In the synced model catalog, composer-2.5 has two variants:

Variant string legacy slug isDefaultNonMaxConfig isDefaultMaxConfig
composer-2.5[fast=true] composer-2.5-fast true true
composer-2.5[fast=false] composer-2.5 not set not set

If fast is omitted, the default variant is Fast.

What the client did

  1. The parent passed a non-fast slug. The child modelId stayed composer-2.5.
  2. Subagent parameters are copied only when the child model id equals the parent model id. The parent was grok-4.7, so the child parameters were cleared. The saved composer-2.5 / fast=false preference was not applied.
  3. The Explore override is reduced to { type: "model", modelId } before the child starts. The stored fast=false parameter is dropped.
  4. With fast missing, catalog default selection uses isDefaultNonMaxConfig, which is the Fast variant.

The parent request still sends its own parameters, which is why Grok stayed non-fast. Only the cross-model subagent lost the parameter.

Builtin Explore’s no-model fallback list is cursor-grok-4.5-high-fast, composer-2.5-fast, cursor-grok-4.5-high, composer-2.5. That list did not decide this run. An explicit composer-2.5 was passed. The missing parameter did.

Fix

When a subagent is composer-2.5:

  • Honor an explicit Task model of composer-2.5 as composer-2.5[fast=false], or require the fast parameter and do not substitute the Fast default.
  • Apply modelParameterPreferences["composer-2.5"] and subagentModelOverrides.explore.selectedModels[0].parameters on the child request. Keep fast=false.
  • If the child model id differs from the parent, resolve that model’s own parameters. Do not send an empty parameter list.
  • Log the fast parameter next to modelId on Selected Agent Host turn runtime, so Fast and standard are distinguishable.

Steps to Reproduce

  1. Set Composer 2.5’s parameter to fast=false.
  2. Set the Explore subagent model to Composer 2.5 with fast=false.
  3. In a Plan chat on Grok 4.7 High, launch an Explore subagent with model: "composer-2.5".
  4. Observe the subagent chip and the usage record: Composer 2.5 Fast.

Parent generation to start from: 62b8a1d8-0a67-4507-9b75-fef98c89e9a2.

Expected Behavior

composer-2.5 with no fast slug, plus a saved fast=false preference and an Explore subagent override of fast=false, should run Composer 2.5 (composer-2.5[fast=false]).

composer-2.5-fast / fast=true should run only when that variant is explicitly selected.

Operating System

Windows 10/11

Version Information

Version: 3.24.9 (user setup)
VS Code Extension API: 1.128.0
Commit: cd6d2a1f2e56e9841f0ed9c7c24542087b4e69b0
Date: 2026-10-08T05:37:28.393Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26300

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hoping that this is a bug and not a “feature” that forces users into fast model subagents when they don’t want.

Hey @Sean_Kaw, thanks for the detailed report and the request IDs.

To answer your follow-up: this isn’t intended behavior. Both Explore subagents ran as Composer 2.5 Fast even though your saved model settings and your Explore subagent setting both have Fast turned off. Nothing in your setup is wrong, and this is an issue we’re tracking.

What you hit happens when the parent chat is on one model (Grok 4.7 here) and the subagent runs Composer 2.5. Two ways to avoid it for now:

  1. Keep Grok 4.7 as the parent and set Cursor Settings > Models > Explore Subagent Model to Inherit from parent. Explore subagents then run on Grok 4.7 with your Fast-off setting instead of Composer 2.5. One catch: if the agent names a model when it launches a subagent, that choice takes priority over this setting. Your two runs were launched with model: "composer-2.5", so if your prompts or rules ask for Composer 2.5 subagents, remove that as well.
  2. Run the parent chat itself on Composer 2.5 with Fast off, so the parent and subagent use the same model.

If a subagent still shows Composer 2.5 Fast with either setup, let me know here. I’ll post here when there’s an update.

Thank you for the quick response. However, neither of these solutions are adequate for my workflow, although I am sure they would work as you described. My work is entirely paused until this issue is resolved. I refuse to pay for Fast.

The issue with your first workaround is that subagents and explore agents would use Grok 4.7 High, which is wasteful. The appropriate model for sub agent and explore use is Composer 2.5. Not Grok 4.7.

The second workaround is slightly better, but limits intelligence during the discussion and planning phase to the Composer model. Again, not ideal, and in some cases will result in major issues.

Can you provide some sort of timeline on when this might be addressed?

Thank you.

Reproduced on 3.24.12 unfortunately.