Task tool `model` parameter only accepts "fast" — cannot specify model IDs for subagents

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

The Task tool’s model parameter only accepts "fast". Passing any specific model ID (e.g. claude-sonnet-4-6, claude-opus-4-6) returns:

Invalid model selection. Available models are: - fast

This contradicts the subagents documentation which states the model field supports three options: inherit, fast, or a specific model ID like claude-4-sonnet or claude-opus-4-6.

Custom subagent frontmatter with model: claude-sonnet-4-6 is also ignored — the tool schema enforces enum: ["fast"] at the parameter level, so the agent cannot even attempt to pass the value.

Steps to Reproduce

  1. Create a custom subagent at ~/.cursor/agents/test-model.md:
---
name: test-model
model: claude-sonnet-4-6
description: Test model selection
---
Say "hello, I am running on claude-sonnet-4-6" and stop.
  1. In an agent conversation, ask the agent to dispatch a Task with model: "claude-sonnet-4-6".

  2. The tool returns the error: Invalid model selection. Available models are: - fast

  3. With model: "fast", the subagent runs but self-reports as Sonnet 4.5, not the requested Sonnet 4.6.

  4. Without the model parameter, the subagent inherits the parent model — there is no way to target a middle-tier model.

Expected Behavior

The Task tool should accept specific model IDs as documented, e.g. claude-sonnet-4-6, claude-opus-4-6, matching the model configuration docs and the agent frontmatter spec.

Error output from Task tool:

Error: Invalid arguments:
model: Invalid model selection. Available models are:
  - fast: Extremely fast, moderately intelligent model...

Tool schema (as presented to the agent):

"model": {
  "description": "Optional model to use for this agent...",
  "enum": ["fast"],
  "type": "string"
}

Operating System

MacOS

Version Information

  • Cursor Agent (CLI): 2026.03.30-a5d3e17
  • Cursor IDE: 2.6.22 (c6285feaba0ad62603f7c22e72f0a170dc8415a0)

For AI issues: which model did you use?

claude-4.6-opus (parent agent), attempting to dispatch claude-sonnet-4-6 (subagent)

Additional Information

it prevents a key workflow. Orchestrator-pattern agents (documented in the subagents docs) rely on dispatching subagents on a middle-tier model for cost/capability balance. The only options today are fast (too weak for complex tasks) or omitting the param (inherits Opus — too expensive for routine work).

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

This is a known limitation. The Task tool’s model parameter currently only supports "fast" for most users. Expanded model selection for subagents (allowing specific model IDs like claude-sonnet-4-6) is not yet generally available.

The model field in subagent frontmatter (.cursor/agents/*.md) is parsed, but if the specified model ID isn’t recognized, the system silently falls back to the parent model. This explains why your subagent runs on the parent’s model rather than the one configured in frontmatter.

A few related threads with the same report:

Our team is aware of this gap and it’s being tracked for the subagents feature. No ETA yet, but reports like yours help with prioritization.

In the meantime, the only model options for subagents are: omit the model parameter (inherits the parent model) or use "fast" (a lighter model optimized for quick tasks).

why did you deprecate/remove the multiple model toggle?!?!?!?! :frowning:

please bring it back!!! please :frowning:

Is there a plan to fix this BUG?

hey @yankle what is your current Cursor CLI version?

v2026.04.15-dccdccd

Title: Task tool subagents always use composer-2-fast — no way to specify or inherit Opus 4.6. No matter what I specify or try to inherit this occurs. I don’t understand how this can happen.

**Environment:**

- Cursor 3.2.21 (Stable, 2026-05-03)

- macOS arm64 25.3.0

- Parent model: Opus 4.6

**Bug:**

When spawning subagents via the Task tool, the only available `model` slug

is `composer-2-fast`. There is no way to:

1. Specify Opus 4.6 (or any other model) as the subagent model

2. Reliably inherit the parent chat’s model selection

This means any multi-agent workflow (orchestrators, research swarms,

review pipelines) silently downgrades to the fast model regardless of

what the user selected. Users paying for premium models get fast-tier

quality on all subagent work with no indication this is happening.

**Expected:** Omitting the `model` parameter should inherit the parent’s

model. Alternatively, all available model slugs should be selectable.

**Impact:** Severe for users running agentic architectures with Task-based

subagent dispatch. All subagent work product is degraded.

I will try to roll back to some version pre-this-bug… Hoping that works. I have invested entirely in Cursor and generated a large amount of adoption CX Engineering. I hope it is clear just how significant this issue is. It seems like something that could be rolled back?

Hey everyone, following up here with an update.

Since my last reply, the team has shipped improvements to subagent model selection. The Task tool’s model parameter now supports more than just "fast" — expanded model slug support has been rolling out in recent versions.

The model selection improvements have landed after some of the versions mentioned in this thread. Updating Cursor should give you access to the expanded subagent model options.

If you’re still seeing subagents default to composer-2-fast after updating and confirming you’re on a paid plan, please share your current Cursor version and a request ID from a failing subagent dispatch so I can trace what’s happening on our end.

cc: @yankle @Ambrose_Taylor

Oh man… this is great news. Really excited to try this update., thank you very much for the update.

@mohitjain

I updated to 3.3.30. Still not working for me

Here’s one: fa9ba721-d527-489f-8390-75cf64ae1bf2

After investigating with your request ID, the root cause is confirmed: accounts on legacy request-based pricing are currently not part of the expanded model selection feature for subagents. This is why the Task tool schema only shows "fast" regardless of Cursor version. Updating to 3.3.30 wouldn’t fix it because the restriction is server-side, tied to your plan type.

The workaround for now: omitting the model parameter lets subagents inherit the parent model (which your logs confirm is working — your subagents are using claude-opus-4-7).

I’ll follow up here if there’s progress on extending model selection to legacy pricing accounts.

Also, when i open the subagent chat itself (click on that card) I always get this “No request ID found”

Not sure why this is so hard, but still stuck in same place. I even see the system statiing the exact same problem “my internal system prompt says I have one model override: composer 2 fast”

THere is some layer that is still hanging around that has not been fixed

I’m having the same issue. Subagents always use Composer 2. I’ve tried creating a custom subagent using the workaround posted at Cursor not respecting my model choice - #7 by kevinn
I’ve tried setting the model in the frontmatter to opus models. I’ve also tried setting it to inherit. I’ve also tried removing the model from the frontmatter entirely. With everything I’ve tried it always uses Composer 2 subagents instead of the model I specify or the model in the parent chat.

Your case is different from the request-based pricing issue discussed above — this looks like the same bug tracked in a separate report where subagents default to Composer 2 regardless of the model specified, even on plans that should support full model selection. Our team is investigating. I don’t have a fix timeline yet, but I’ll update this thread when there’s progress.

Sorry you’re still stuck. A couple of things:

  1. The “composer 2 fast” override — could you confirm you’re not specifying a model parameter anywhere (in the Task tool call or in a custom subagent file)? Omitting it entirely should let the subagent inherit the parent model. If you’re still seeing the override with no model specified, could you share a screenshot of the system prompt message you mentioned?

  2. “No request ID found” — this is expected for subagent chats right now. To get the Request ID, copy it from the parent chat (three dots menu > Copy Request ID) rather than from the subagent card. That parent request ID lets us trace the full conversation including subagent calls.

If the workaround genuinely isn’t working with model omitted, I’ll need that parent Request ID to dig into what’s happening server-side.

So hang on. The way to get model to propagate is via inherit? This is true even now? That’s how I had it before and didn’t work, then I read your message > upgraded > specified model from model options in subagent UI drop down.

I will try this, but it’s not ideal and not sure I’ll end up using inherit. What if I use a main chat model that doesn’t work as a inheritable model?

It keeps telling me it has an internal system prompt that locks it to single model. Can you explain that part, and if you can not have it in its prompt? Is it some deeper problem with corps you don’t control getting context handoff between agents? I genuinely curious to understand why it is such a technical challenge that a big this significant would state open so long.

At this point I just took the hit and stayed up till 3am last night to rearchitect my harness, and it’s working better now. But in its new design inherit is not desirable. I’ll test for you but hopefully you can get model specification working

Thanks,

Ambrose Taylor, CCIE# 60254

Software Engineer Technical Leader

Global CX Centers

Email: [email protected]

I’ll just add one last thing. Stable existing features first, enhancements and new things next…

When I see a bunch of new stuff coming out I just think “don’t care, just want core low level stuff working.” When subagents came out it was profound. I fell in love and started building my tooling around it. It unblocked some cumbersome problems in my workflow. But the. It just never worked right. To guys like me that’s really problematic. It’s a base capability that I really need, more than anything else. I just want what’s there now to work.

Same issue with inherit. Main chat is 5.5-high which shows as a supported option

Invoked subagent in main chat

name: e2e-kcs

model: inherit

description: Pre-release QA gate for the ccw_kcs widget. Enumerates open KFB candidate fixes on the active branch, proves each via Flow A (per-Jira) or Flow B (full regression), and writes verdict back to Jira (qa-pass / qa-block).

Request ID e0288a0b-1dcb-48e9-b67e-0c5e49aee1fd

Saw cursor

It is still not workin at all in any fashion