Subagent model selection architecture is broken across IDE, CLI, and Cloud Agents: `<available_subagent_models>` is locked to last-clicked UI dropdown effort, CLI strips non-`defaultOn` models (`gemini-3.8-flash`), and mismatches silently fall back

[Richard_W]

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Individual threads keep getting filed, acknowledged as “known issues,” and auto-closed 2–30 days later whenever a specific model (gemini-3.8-flash, grok-4.7-xhigh, composer-2.5, etc.) fails to launch as a subagent (e.g. #170678, #173203, #173474, #175674).

The root problem is not a single missing model slug. The architecture of how Cursor constructs selected_subagent_models / <available_subagent_models> across the IDE, CLI, and Cloud Agents is fundamentally broken for multi-agent orchestration.

A deterministic multi-agent workflow that passes evals on specific models/efforts cannot run reliably across Cursor IDE, Cursor CLI (agent), and Cloud Agents because of four compounding root causes:

1. IDE <available_subagent_models> Is Coupled to the Last-Clicked Dropdown Effort

In the Cursor IDE, the Task tool’s <available_subagent_models> allowlist only exposes one reasoning effort / Fast variant per visible model — whichever variant happened to be last selected in the user’s interactive chat dropdown (RunInferenceRunRequest.selected_subagent_models).

• In my attached screenshot, my IDE dropdown has Claude Opus 5.5 Medium, Gemini 4 Argon High, Muse Wonder High, GPT-5.6 Sol High, Claude Fable 5.1 1M High, Gemini 3.8 Flash High, and Grok 4.7 High.
• Because of that dropdown state, the entire <available_subagent_models> block injected into the parent agent for the session is:

  - inherit (default; required unless the user explicitly requested another model)
  - claude-fable-5-1-thinking-high
  - claude-opus-5-5-medium
  - claude-sonnet-5-5-high
  - composer-2.5{,-fast}
  - gemini-3.8-flash-high
  - gemini-4-argon-high
  - gpt-5.6-sol-high
  - grok-4.7-high
  - muse-wonder-1.0-high
  

• If the parent agent or a shared project rule/skill requests gemini-3.8-flash-medium, claude-fable-5-1-thinking-low, claude-opus-5-5-high, or grok-4.7-xhigh-fast, the Task tool rejects it (Invalid model selection "...". Model could not be resolved to a valid subagent model.).
• Worse, it is impossible to use two effort levels of the same model family in one session (e.g., claude-fable-5-1-thinking-low for fast synthesis workers and claude-fable-5-1-thinking-high for deep security audit workers), because switching the dropdown to Low removes High from <available_subagent_models>, and switching it to High removes Low.
• Staff confirmed this in #172552 (post #18) and #161056 (post #19): “Right now the Task tool only offers one reasoning level per model, and it’s whichever level (and Fast setting) is currently selected for that model in your model picker.”

2. Cursor CLI Strips Non-defaultOn Models (Such as gemini-3.8-flash) From selectedSubagentModels

In Cursor CLI (2026.10.22-27dcf5f, Ultra tier), agent --list-models explicitly lists gemini-3.8-flash-low, gemini-3.8-flash-medium, and gemini-3.8-flash-high. Yet attempting to spawn a Gemini 3.8 Flash subagent in the CLI fails with:

"Note on model selection: gemini 3.8 flash is not available in the subagent model catalog for this session"

Inspecting the CLI bundle (1623.index.js → ./src/model-request-format.ts) shows why:

const r = e.modelManager.getParameterizedModels(),
      i = r.filter((e => e.supportsAgent && (e.defaultOn ?? !1)));
if (r.length > 0 && i.length > 0)
  return {
    selectedSubagentModels: i.map((t => ({
      modelId: t.name,
      maxMode: !0 === e.parentMaxMode,
      parameters: void 0 !== e.configProvider
        ? e.modelManager.getParametersForModel(t.name, e.configProvider)
        : []
    }))),
    ...t
  };

Because the CLI has no UI visibility picker, it filters getParameterizedModels() by e.defaultOn ?? false and attaches only the single parameter tuple from getParametersForModel(). Any entitled model where default_on is false on the server (like gemini-3.8-flash) is stripped out of selectedSubagentModels before the session starts.

3. Incompatible Slug Formats (slug[params] vs Hyphenated Slugs) Across Surfaces

There are three conflicting ways to specify a model variant across Cursor, and none work consistently across IDE, CLI, and Cloud:

• Hyphenated slugs (gemini-3.8-flash-medium, claude-fable-5-1-thinking-low): Required by the Task tool model argument and CLI --model, but rejected unless that exact effort/speed tuple is currently active in the UI picker.
• Bracket parameter syntax (model: claude-opus-5[effort=high]): Documented in Subagents | Cursor Docs for .cursor/agents/*.md frontmatter, but rejected if passed directly to Task(model=...) or CLI --model (#163645 post #10).
• Undocumented per-vendor parameter keys: The docs state to use effort=high, but on Grok 4.7 model: grok-4.7[effort=xhigh,fast=true] fails or silently runs on Opus because Grok 4.7 requires reasoning_effort=xhigh instead of effort=xhigh — and still fails with Invalid parameters for registry model: "grok-4.7" if the UI picker context window is set to 500K instead of 256K (#173474).

4. Silent Model Substitution & Fallback (Security, Eval Drift, and Billing Hazard)

In extensions/cursor-agent-host/dist/agent-host-daemon/dist/bin/daemon.cjs (resolveSubagentModel, line 13925), when a subagent’s configured userRequestedModelId fails isModelValid(userRequestedModelId) against the session’s allowlist, it does not fail loudly:

if (!isModelValid(userRequestedModelId)) {
  if (await isParentModelUsable()) {
    return logResolvedModel({
      resolvedModelId: parentModelId,
      modelResolutionReason: "user_requested_model_invalid_fallback_parent",
      reasonDetails: { userRequestedModelId, parentModelId }
    });
  }
}

And if that falls through, it silently falls back to subagent_default_model (Composer). Unless you are actively watching internal trace logs:

• A cybersecurity or code-audit subagent tested and validated on Claude Fable / Opus can silently fall back to Composer or another model when a dropdown setting shifts.
• Specialized author/verifier agents that pass 100% of evals on Model X at Effort Y silently run on Model Z when pushed to CLI or Cloud Agents.
• Conversely, parent agents and Cloud Agent helpers spawning unrequested Opus/Sonnet/Fast models drain users’ API budgets and prepaid credits (#162601, #169638, #174235).

Steps to Reproduce

Repro A: IDE Dropdown Effort Lock (<available_subagent_models>)

1. In Cursor IDE, open the chat model picker dropdown and set Gemini 3.8 Flash to High effort (and Claude Fable 5.1 to High, Claude Opus 5.5 to Medium).
2. Start a new Agent session and inspect <available_subagent_models> (or ask the parent agent to spawn a Task subagent with model: "gemini-3.8-flash-medium" or model: "claude-fable-5-1-thinking-low").
3. Observe that <available_subagent_models> only contains the single effort variant currently highlighted in the dropdown (gemini-3.8-flash-high, claude-fable-5-1-thinking-high, claude-opus-5-5-medium).
4. Invoking Task with gemini-3.8-flash-medium or claude-fable-5-1-thinking-low fails immediately with:
   Invalid model selection "gemini-3.8-flash-medium". Model could not be resolved to a valid subagent model.

Repro B: Cursor CLI Missing Non-defaultOn Models (gemini-3.8-flash)

1. In terminal on Ultra/Pro plan, run agent --list-models and confirm gemini-3.8-flash-low, gemini-3.8-flash-medium, and gemini-3.8-flash-high are all listed as available models.
2. Start a Cursor CLI agent session and ask it to launch a subagent via Task using gemini-3.8-flash (or any of its effort slugs).
3. Observe failure: "Note on model selection: gemini 3.8 flash is not available in the subagent model catalog for this session" because ./src/model-request-format.ts filters selectedSubagentModels by e.supportsAgent && (e.defaultOn ?? false).

Repro C: Silent Fallback on Mismatched Subagent Frontmatter Pin

1. Define .cursor/agents/auditor.md with model: claude-fable-5-1-thinking-low (or model: grok-4.7[effort=xhigh,fast=true]).
2. In the IDE, have Claude Fable 5.1 set to High in the dropdown (or parent on Composer / Opus), and ask the parent agent to invoke the auditor subagent without passing an explicit model argument in the Task call.
3. Observe in runtime logs (daemon.cjs → resolveSubagentModel) that validation fails and the subagent silently falls back via user_requested_model_invalid_fallback_parent or subagent_default_model instead of running the pinned model/effort or raising an explicit configuration error.

Expected Behavior

1. Decouple <available_subagent_models> / selected_subagent_models from the UI chat dropdown’s active effort state:

   • Any model family the user’s account/team is entitled to (and hasn’t disabled) must accept all valid reasoning-effort and speed variants in Task(model=...) and .cursor/agents/*.md, regardless of which single effort level is currently highlighted in the IDE chat dropdown or whether default_on is false in the CLI.
   • To keep prompt tokens compact in <available_subagent_models>, use the existing compactSubagentModelSlugs brace expansion already implemented in daemon.cjs (e.g., gemini-3.8-flash-{low,medium,high}, claude-fable-5-1-thinking-{low,medium,high,xhigh,max}, grok-4.7-{low,medium,high,xhigh}{,-fast}).

2. Unify model identifier syntax across IDE, CLI, Cloud Agents, Task, and .cursor/agents/*.md:

   • Accept both canonical hyphenated slugs (gemini-3.8-flash-medium) and bracket syntax (gemini-3.8-flash[effort=medium]) everywhere (Task tool model param, .cursor/agents/*.md frontmatter, CLI --model, and Cloud Agent API).
   • Normalize effort and reasoning_effort as aliases so users aren’t hit with undocumented per-vendor key mismatches (#173474).

3. Fix Cursor CLI ./src/model-request-format.ts:

   • Stop filtering selectedSubagentModels by e.defaultOn ?? false so all entitled agent-capable models (matching agent --list-models) are available to CLI subagents.

4. Never silently substitute a different model when an explicit model is requested:

   • If a subagent frontmatter or Task call explicitly specifies a model or parameter that cannot be satisfied, fail loudly with the exact rejected parameter and valid options instead of silently falling back to the parent model or Composer (user_requested_model_invalid_fallback_parent).

Screenshots / Screen Recordings

Operating System

Windows 10/11
MacOS
Linux

Version Information

IDE:
Version: 3.27.12
VSCode Version: 1.128.0
Commit: df132ffba90dfc15a12e6b8f020ba4e5d026c4b0
Date: 2026-10-23T02:27:47.076Z
Node.js: 24.22.1
OS: Linux x64 6.8.0-137-generic

CLI (agent about):
CLI Version: 2026.10.22-27dcf5f (Latest, up to date)
Subscription Tier: Ultra
OS: linux (x64)

For AI issues: which model did you use?

Parent models: Gemini 4 Argon High, Composer 2.5, Claude Opus 5.5, GPT-5.6 Sol High
Target subagent models affected: gemini-3.8-flash (low/medium/high), claude-fable-5-1-thinking (low/medium/high), claude-opus-5-5 (medium/high), grok-4.7 (high/xhigh/fast), composer-2.5 (standard vs fast)

Additional Information

Why Existing Workarounds Do Not Solve This (Please Do Not Close With These)

• “Set Settings → Models → Explore Subagent Model”: As staff confirmed in #161056 and #175721, that setting only applies to the built-in explore subagent, not generalPurpose, custom .cursor/agents/*.md, or explicit Task(model=...) calls.
• “Set the parent chat to the desired model and use model: inherit”: Multi-agent orchestration intentionally uses different models/efforts for different worker roles (e.g., Grok 4.7 or Gemini 3.8 Flash for fast parallel exploration, GPT-5.6 Sol or Opus 5.5 for implementation, Fable 5.1 Low for synthesis). inherit forces every worker onto the parent’s single model and effort level.
• “Toggle the model and effort level in the IDE dropdown before starting chat”:
  1. You still cannot use two effort levels of the same model family (e.g. low and high) in the same session.
  2. It does not work in headless Cursor CLI (agent) or Cloud Agents API (#170072).
  3. Changing the chat dropdown mid-day silently breaks repo-checked rules and custom subagents for the whole team.

Corroborating Forum Threads (Many Auto-Closed While Root Cause Remains)

1. #170678 — Task tool allowlist missing Gemini 3.8 Flash (gemini-3.8-flash) after model launch (Auto-closed Oct 25, 2026 with unanswered follow-ups)
2. #172552 — Cursor Live Task Allow List does not include Grok 4.7 (Post #18 confirms only the single dropdown-selected effort level is exposed to Task, dropping xhigh when high is selected)
3. #173474 — Custom subagent pinned to Grok 4.7 Extra High Fast runs on Opus or is rejected (Auto-closed after 2 days; confirms effort vs reasoning_effort mismatch, 500k context picker state breaking Task dispatch, and silent fallback to Opus)
4. #161056 — Only 4 subagent models available (Posts #12 & #19 confirm Task only receives the single pinned variant per visible model in the picker)
5. #175674 — Task subagent model composer-2.5-fast fails; composer-2.5 rejected; inherit works (Auto-closed after 2 days; documented slug composer-2.5 rejected by Task allowlist when Fast is selected in picker)
6. #173154 — Composer subagents run on Fast when the parent chat isn’t Composer, ignoring the agent file’s [fast=false] pin
7. #174235 — Subagent model composer-2.5 drops fast=false and runs Composer 2.5 Fast
8. #166860 — Sub-agent runner completely ignores model constraint in local definition files (Auto-closed after 2 days; confirms frontmatter model: is overridden by parent and invalid slugs silently fall back to parent model)
9. #163645 — Subagent Model Choice Not Respected (Post #10 confirms bracket syntax slug[effort=high] is not supported by CLI --model)
10. #162601 — Parent agent overrides subagent model settings by explicitly passing model to Task tool - It used all of my api budget
11. #169638 — Cloud Agent logs claude-4-5-sonnet when picker is Grok 4.6 and Claude is not enabled (34 posts; confirms IDE model settings do not constrain Cloud Agent helper/subagent model selection)
12. #170072 — Control Over Subagent Model Selection in Cloud Agent API (Confirms Cloud Agent API has no way to enforce subagent model selection across built-in helpers)
13. #167898 — Cursor-Agent spawning subagents of models i did not select? (Post #5 confirms CLI cursor-agent lacks a full model catalog for subagents)

Please keep this topic open as a canonical tracking thread rather than auto-closing 2 days after a “we are tracking this” reply, as the underlying catalog architecture across IDE, CLI, and Cloud Agents still needs a unified fix.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Colin]

Hi @Richard_W,

Two of these match what the code does today. The Task model list only carries the variant (effort and Fast setting) currently selected for each model in your picker. The CLI builds its list only from models that are enabled by default, which is why Gemini 3.8 Flash is missing from it. The first is a known issue the team is tracking, and I’ve added your report to it. I’ve passed the CLI one along as well.

On the slug formats: bracket parameters are meant for .cursor/agents frontmatter, and the parameter names depend on the model. Grok 4.7 expects reasoning_effort, not effort.

On the fallback: when a pinned model can’t be used, it falls back to a compatible model as the docs describe. Newer builds also tell the parent agent which model actually ran.

In the meantime, set the picker to the effort you want before starting the chat. In the CLI, a frontmatter pin like model: gemini-3.8-flash-medium is checked against your plan rather than that list, so it may be worth a try.

[Richard_W]

Thanks @Colin, appreciate you passing this to engineering.

To give context on why I dug through the transcripts and daemon logs (burning ~200M tokens on Opus, Argon, and Fable just to prove what was happening under the hood): I have a team of 15 using a mix of IDE, Cloud Agents for scale, and now CLI as a last resort. When a project moves across Cloud Agent → CLI → IDE, model selection completely falls apart.

A few realities from trying to make this work in production:

• Frontmatter pins don’t save us: In our testing (especially on Cloud Agents), frontmatter pins frequently hard-failed and stopped the agent immediately. It got so bad we had to instruct our orchestrator to first spawn a dummy subagent with model: "not-a-real-slug" just to force an error that would dump the actual available models for that session.
• Pre-setting the UI picker doesn’t work for orchestration: We had high hopes for a pstack-style model routing rule, where one workflow uses Low effort for fast tasks and High/Max for complex ones in the same run. A single GUI dropdown state can’t handle multi-agent fan-out, and it breaks the moment that repo runs in CLI or Cloud.
• Silent fallbacks break trust: Even if the parent agent gets a note about which model actually ran, the wrong model already executed the task (and billed the tokens).
• Forum threads getting closed: Part of the frustration is seeing related threads on this topic get auto-closed while unresolved, which makes it feel like the issue is being brushed under the rug.

At the very least, if unifying the catalog across IDE, CLI, and Cloud takes time, please give us a middleware hook or config map where we can intercept and control model/effort resolution ourselves across surfaces. Right now, cross-surface orchestration is fighting the harness at every step.