Bug: Subagent model enum appears capped by parent GPT-5.5 reasoning effort

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I ask the parent agent to create or run subagents with GPT-5.5 reasoning variants, the available subagent model choices appear to be capped by the parent agent’s current GPT-5.5 reasoning effort.

The higher reasoning variants are available in the main model picker. The issue only shows up when a parent agent tries to create/invoke subagents.

Observed behavior:

Parent agent: GPT-5.5 xhigh
Subagent: GPT-5.5 high/xhigh works

Parent agent: GPT-5.5 high
Subagent: GPT-5.5 xhigh is reported unavailable, high still works

Parent agent: GPT-5.5 medium
Subagent: GPT-5.5 high/xhigh is reported unavailable, medium still works

I did not create a custom subagent markdown file with frontmatter for this test. I only asked the agent in the prompt to create subagents with a specific model.

The agent output mentioned that the requested stronger subagent model was unavailable and then asked whether it could switch to another model. I do not have the original subagent error text or an Available models are... list.

This feels similar to other subagent model selection issues reported on the forum, but the specific pattern here is that the parent reasoning effort seems to act as a ceiling for the subagent model enum.

Steps to Reproduce

  1. Open Cursor IDE desktop.
  2. Start a new chat.
  3. Select GPT-5.5 xhigh as the parent agent model.
  4. Ask the agent to create/run a subagent using GPT-5.5 xhigh or GPT-5.5 high.
  5. Observe that the subagent can run with those higher reasoning variants.
  6. Start another new chat.
  7. Select GPT-5.5 high as the parent agent model.
  8. Ask the agent to create/run a subagent using GPT-5.5 xhigh.
  9. Observe that the agent reports xhigh as unavailable and asks to switch models.
  10. Start another new chat.
  11. Select GPT-5.5 medium as the parent agent model.
  12. Ask the agent to create/run a subagent using GPT-5.5 high.
  13. Observe that high is reported unavailable and the agent falls back to, or asks to use, a lower available model.

Expected Behavior

If GPT-5.5 medium, high, and xhigh are enabled, visible in the main model picker, supported for Agent mode, and available on the account, an explicitly requested subagent model should not be capped by the parent agent’s current reasoning effort.

For example, I should be able to run the parent agent at GPT-5.5 medium for cost control while assigning a specific subagent to GPT-5.5 high or GPT-5.5 xhigh for verification, architecture review, or harder reasoning tasks.

Operating System

MacOS

Version Information

Version: 3.7.12
VS Code Extension API: 1.105.1
Commit: b887a26c4f70bd8136bfffeda812b24194ec9ce0
Date: 2026-06-05T01:45:12.918Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

GPT 5.5

For AI issues: add Request ID with privacy disabled

parent Request ID: 755e82ea-33a5-4fde-a344-add37a28c42d

Additional Information

This may be related to the existing subagent model selection issues where subagents inherit or fall back to the parent model. The difference in this case is that the behavior looks like a reasoning-effort ceiling rather than a full fallback:

  • xhigh parent can create/use xhigh subagents.
  • high parent cannot use xhigh subagents.
  • medium parent cannot use high or xhigh subagents.

If this is expected behavior, it would be helpful to document that subagent reasoning effort cannot exceed the parent agent reasoning effort. If it is not expected, the Task/Subagent tool model enum may be getting filtered too aggressively based on the parent model.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Thanks for the detailed write-up and clean repro. You’ve basically diagnosed it correctly.

It’s not an intentional reasoning “cap,” but the current behavior does land there. The models offered to a subagent come from the ones enabled and visible in your main model picker. For a given family, the reasoning level offered matches whatever that family is currently set to in the picker. So with GPT-5.5 set to medium, the only GPT-5.5 option a subagent gets is gpt-5.5-medium. It’s pinned to that one variant, so it can’t go above (or below) the parent’s current level.

The pin only applies within a family, which gives you a workaround: keep GPT-5.5 at medium for the parent, set a different family (a Claude or Gemini variant) to a higher reasoning level in your picker, then delegate the heavy lifting to that model as the subagent. If you specifically want a higher-effort GPT-5.5 subagent, you’d need to raise GPT-5.5’s reasoning in the picker, which also raises the parent.

One note: the model field for a custom subagent takes a family-level ID like gpt-5.5, not a specific reasoning variant, so it follows the same picker setting.

This is a known limitation in how subagent model selection works today, and it’s an area we’re actively improving. Mixing reasoning efforts within a single family isn’t supported yet.

8

That’s very limiting and limits many legitimate use cases, like automated reviews by progressively more capable models and effort level pairs of a family. Pls enable this.

9

You can actually build this today with custom subagents - the cap only applies to spawning subagents on the fly from chat.

Correcting my earlier note above: a custom subagent’s model field does support a specific effort level, via bracket parameters. Create a file in .cursor/agents/ (project) or ~/.cursor/agents/ (all projects):

---
name: deep-reviewer
description: Reviews changes with higher-effort reasoning.
model: gpt-5.5[effort=high]
---

The model field takes id=value params like effort= and context=, so you can define a chain of reviewers — each pinned to a progressively more capable model/effort — and invoke them with /deep-reviewer (or run several in parallel). See Subagents → Model parameters.

The on-the-fly case (asking in chat to launch a higher-effort same-family subagent) still follows your model picker - that’s the part we’re improving, and threads like this help us prioritize it. One caveat: on legacy request-based plans without Max Mode, subagents fall back to Composer regardless of the model field.

10

Hi @mohitjain many thanks!

Will this also work for models that the user didn’t enable in Cursor settings for general work?