Where does the bug appear (feature/product)?
Cloud Agent (GitHub, Slack, Web, Linear)
Describe the Bug
TL;DR
I write plans that assign each task a subagent and an exact model slug from the models I have enabled for chat. When I ask the parent agent to run that plan, Task often cannot take the slug the plan named, because Cursor bakes a smaller, frozen model enum into the tool schema. Chat-allowed should mean Task-allowed. If the plan says Grok (or any other enabled model), the subagent must run that model — not inherit, not substitute, not stop because the enum omitted it.
This is all in a remote-control cloud-agent connected to a linux machine; the IDE is in Windows 11
Detail
I write implementation plans that split work into a task DAG. Each task names a subagent and an exact model slug. Those slugs are models I have enabled and that appear on the chat allowed list. When I later ask the parent agent to execute that plan with subagents, the Task tool often cannot take the model the plan recorded, because Cursor injects a smaller, frozen model enum into the agent’s tool schema.
That breaks the contract I am trying to enforce: plan says model X → Task must run model X, as long as X is on my enabled/allowed chat models. I am not asking for hidden models, unpaid models, or admin-blocked models. I am asking to use, on a subagent, the same models I am already allowed to select for chat.
What I am doing
Enable models in Settings → Models (they show in the chat picker).
In a plan, each task has a field like Model: cursor-grok-4.5-high (or another enabled slug). The plan also says: never substitute a different model for a task.
I ask the parent agent to implement the plan using subagents according to the DAG, passing that slug into Task.
The parent’s Task schema was baked at session start and lists only a subset, for example:
inherit
claude-fable-5-thinking-high
composer-2.5
gpt-5.6-luna-high
gpt-5.6-sol-high
gpt-5.6-sol-xhigh
Grok 4.5 is enabled for chat in this account, but not in that enum. The parent is instructed not to pass a slug that is not listed. So it cannot execute the plan as written: it must omit model, substitute a listed slug, or stop.
Why this is wrong
The plan is the source of truth for which model runs which task. Chat availability is the source of truth for whether I am allowed to use that model. Task’s enum is a third, narrower list that neither the plan nor Settings → Models describes. That third list is what actually runs.
Consequences:
I cannot pin Grok (or any other chat-enabled model missing from the enum) on a DAG task and have a subagent honor it.
Changing Settings mid-session does not refresh the schema; even a new session may still expose only one variant per family.
There is no “subagent allowed models” setting. Workarounds (inherit, custom agent frontmatter, disabling other models) are not “run the model the plan named.”
Cursor staff have already described this behavior: Task slugs “mirror the model picker with a single variant per family”; exposing all variants on Task is a “known limitation”; a broader subagent allowlist “doesn’t exist yet.”
Requested fix
If a model is on my chat allowed/enabled list, it must be a valid Task model slug, including the effort/fast variant I named in the plan.
Parity: chat-enabled model ⇒ Task-accepted slug. No silent subset.
Plan execution: the parent must be able to pass the exact slug from the plan. If the slug is invalid, error; do not omit it from the schema so the agent cannot even attempt it.
Snapshot: either refresh the Task enum when Settings → Models changes, or show in the UI that subagent models are a session snapshot and how to rebuild it.
Control: if you keep a filter, make it an explicit setting defaulting to all chat-enabled models.
I am not asking you to pick the model for me. I already did that in the plan, from the allowed list. Task has to accept that choice.
Related:
Subagent Allowed Models
Task accepts Grok 4.5 Low Fast but executes Composer 2.5
Steps to Reproduce
In Cursor Settings → Models, enable Grok 4.5 (or any model you intend to pin). Confirm it appears in the chat model picker and that you can run the parent agent on it.
Leave other models enabled as well (Composer, Claude, GPT, etc.). Do not hide everything except Grok — the point is mixed chat availability.
Start a new Agent chat with a parent model that is not Grok (for example Composer 2.5 or Grok 4.6).
In that chat, ask the agent to inspect the Task/subagent tool schema and list every value accepted by the model parameter.
Observe that the enum is a subset of chat-enabled models. In this session it was:
inherit
claude-fable-5-thinking-high
composer-2.5
gpt-5.6-luna-high
gpt-5.6-sol-high
gpt-5.6-sol-xhigh
Grok 4.5 was enabled for chat and absent from this list.
Write a plan (for example .cursor/plans/example.plan.md) whose DAG has a task like:
T1
Model: cursor-grok-4.5-high (or the exact Grok slug shown in your picker)
plus: never substitute a different model for a task.
In the same Agent chat, ask: implement this plan using subagents according to the DAG, and pass each task’s recorded model slug into Task.
Expected: Task launches T1 on cursor-grok-4.5-high.
Actual: the parent cannot pass that slug because it is not in the baked enum. It must omit model, substitute a listed slug, or stop. Changing Settings → Models in this chat does not add Grok to the enum.
Optional checks:
Repeat step 3–5 in a new session after setting the picker to Grok 4.5 High. The Task enum may still omit Grok or only include one variant per family.
Confirm there is no Settings control for “models allowed on subagents.”
Expected Behavior
Should run the subtasks with the selected models from the allowed list of models (e.g. grok-4.6)
Operating System
Linux
Version Information
Version: 3.17.19 (system setup)
VS Code Extension API: 1.128.0
Commit: ae3a2b7231dd56194447fe4570dfdc61640b1e90
Date: 2026-08-24T06:42:14.583Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200
Does this stop you from using Cursor
No - Cursor works, but with this issue