SubAgent Task tool ignores model-specific subagent_type routing — all subagents inherit parent model instead of using their designated models (opus/codex)

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

SubAgent Task calls ignore subagent_type-implied model routing and instead inherit the parent agent’s model.
When using the Task tool with model-specific subagent_type values (e.g., planner-opus, plan-reviewer-codex, final-gate-opus), the subagents do not run on the models indicated by their type names. Instead, they appear to inherit the parent agent’s model, effectively ignoring the model binding that the subagent_type names suggest.

Steps to Reproduce

  1. Open a Composer session (Plan mode was used, but likely reproducible in Agent mode)
  2. Instruct the agent to sequentially call three subagents:
    • Task(subagent_type=“planner-opus”, …)
    • Task(subagent_type=“plan-reviewer-codex”, …)
    • Task(subagent_type=“final-gate-opus”, …)
  3. None of the Task calls specify an explicit model parameter
  4. Observe that all three subagents appear to run on the same model as the parent agent, rather than on their respective designated models (opus / codex / opus)

Expected Behavior

Each subagent_type with a model identifier in its name should automatically route to the corresponding model on the backend:

subagent_type Expected Model
planner-opus opus
plan-reviewer-codex codex
final-gate-opus opus
code-reviewer-codex codex
coder-codex codex
code-final-review-opus opus
test-writer-codex codex

This routing should happen regardless of the parent agent’s model.

Operating System

MacOS

Version Information

Version: 2.4.37
VSCode Version: 1.105.1
Commit: 7b9c34466f5c119e93c3e654bb80fe9306b6cc70
Date: 2026-02-12T23:15:35.107Z (2 天前)
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

For AI issues: which model did you use?

Sonnet4.6

For AI issues: add Request ID with privacy disabled

privacy enable

Additional Information

  • Conversation ID: d14830f3-1ea3-4910-96ba-c46a17c967ca
  • Composer ID: 48c6f83d-38c5-408c-ac26-26f0571e4027
  • Composer mode: Plan
  • Parent model: claude-4.6-opus-high-thinking (or whichever model was active at the time)
  • Cursor version: Latest as of 2026-02-15
  • OS: macOS (darwin 25.2.0)

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report.

The subagent_type parameter in the Task tool is just a name or identifier. It doesn’t control which model gets run. Adding “opus” or “codex” to the name doesn’t enable automatic model routing.

To assign a specific model to a subagent, set the model field in the subagent’s YAML frontmatter. Create .cursor/agents/planner-opus.md:

---
name: planner-opus
description: Task planning using Opus.
model: claude-4.6-opus-high-thinking
---

Your prompt here...

Valid values for model:

  • inherit uses the parent agent’s model
  • fast uses a faster, cheaper model
  • A specific model name, like claude-4.6-opus-high-thinking or gpt-5.2-codex

Docs: Subagents | Cursor Docs

I also noticed related feature request here: Feature Request: Recursive Subagents, CLI Support, and Flexible Model Selection for Task Tool. The team is aware of the request to set models dynamically at call time. There’s no ETA yet, but reports like this help with prioritization.

Let me know if setting the model via frontmatter works for your workflow.

Thanks for the reply, Dean.

I actually already have the model field configured in the YAML frontmatter for all 7 of my subagents. Here’s what my .cursor/agents/ directory looks like:

Agent file model in frontmatter
planner-opus.md claude-4.6-opus-high-thinking
plan-reviewer-codex.md gpt-5.3-codex-xhigh
final-gate-opus.md claude-4.6-opus-high-thinking
code-reviewer-codex.md gpt-5.3-codex-xhigh
coder-codex.md gpt-5.3-codex-xhigh
code-final-review-opus.md claude-4.6-opus-high-thinking
test-writer-codex.md gpt-5.3-codex-xhigh

For example, my planner-opus.md frontmatter:

-–

name: planner-opus

model: claude-4.6-opus-high-thinking

description: xxx

readonly: true

-–

The issue is that even with model explicitly set in frontmatter, the subagents still appear to inherit the parent agent’s model rather than using their designated ones. So the frontmatter approach doesn’t seem to be working either — which is why I filed this as a bug rather than a feature request.

Is there any way to verify which model a subagent is actually running on? That would help confirm whether the frontmatter model field is being picked up at all.

Related question: How can we obtain exact string id for models available in Cursor (more reliable than browsing Claude / Codex official docs)? What is the correct name for “auto” or Composer models?

1 Like

Thanks for the extra details, this is a confirmed bug. The model field in frontmatter can currently be ignored under certain conditions. Another user reported the same thing here: Subagent with `model: inherit` doesn't actually inherit parent model (uses composer-1 instead). A fix is expected in version 2.5.

A couple questions to help the team debug:

  1. Can you share the Request ID (Chat context menu > Copy Request ID) with Privacy Mode turned off? That lets us verify on the backend which model is actually being used for subagents.
  2. Are you on the usage-based plan or the legacy request-based plan? (You can check at https://cursor.com/dashboard?tab=usage. If it shows dollars instead of a request count, you are on usage-based.)

@DjWarmonger: There is no exact public list of all model string IDs in the docs. The most reliable way is to check the model dropdown in Cursor (the model picker in chat). The model values in subagent file frontmatter should match what you see in the model picker. For “auto”, you can try auto or just leave out the model field.

Thanks for confirming this is a bug, Dean. Good to hear a fix is expected in v2.5.

To answer your questions:

  1. Plan type: I’m on the usage-based plan (dashboard shows dollar amounts).

  2. Request ID: Unfortunately I’m unable to turn off Privacy Mode due to policy constraints, so I can’t provide a Request ID with privacy disabled. If there’s anything else I can provide without disabling Privacy Mode, happy to do so.