Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Custom subagents pinned to Grok 4.7 Extra High Fast either run on Opus, or are rejected before they start.
There are two failure modes:
-
If the parent agent launches the subagent without an explicit model argument, and relies on the model pinned in ~/.cursor/agents/NAME.md, the subagent runs on Opus instead of Grok 4.7.
-
If the parent agent passes the only Grok 4.7 slug that the Task tool lists as available, grok-4.7-xhigh-fast, the launch fails immediately with:
Error: AI Model Not Found
Invalid parameters for registry model: “grok-4.7”
The slug is advertised as a valid Task model in the same session, then rejected when it is used. The error quotes the base id “grok-4.7”, which looks like the client splits grok-4.7-xhigh-fast into a registry model plus parameters (effort=xhigh, fast=true) and the registry rejects that parameter set.
The same error happens after removing context=500k from the agent file, so this is not caused by that context setting.
Steps to Reproduce
- Create ~/.cursor/agents/implementer.md with:
name: implementer
model: grok-4.7[effort=xhigh,fast=true]
-
From a parent agent, launch a Task subagent with subagent_type “implementer” and no model argument.
Observed: the subagent model is Opus. -
Launch the same Task with model “grok-4.7-xhigh-fast”.
Observed, immediately, no subagent output:
Error: AI Model Not Found
Invalid parameters for registry model: “grok-4.7”
- This explicit-slug failure was reproduced three times with the same arguments: twice while the agent file still contained context=500k, and once after that token was removed, leaving model: grok-4.7[effort=xhigh,fast=true].
A later launch that again omitted model (to retest the updated agent-file pin) was cancelled before it returned, so there is no second observation of the Opus fallback after the config edit.
I have not confirmed whether Grok 4.7 Extra High Fast works in a normal non-subagent chat. This report is only about the subagent / Task path.
Expected Behavior
Launching subagent_type implementer or reviewer should use the model pinned in that agent file: Grok 4.7, extra-high effort, fast.
If the parent must pass a model explicitly, model “grok-4.7-xhigh-fast” should start that same variant, because that slug is in the session’s allowed Task model list.
If that variant is not actually entitled, the Task allow-list should not offer the slug, and the error should name the rejected parameter (effort, fast, or something else) instead of only: Invalid parameters for registry model: “grok-4.7”.
A missing or unhonored pin should not silently fall back to Opus.
Operating System
MacOS
Version Information
IDE (read from the installed Cursor.app product.json, not from Help > About):
Version: 3.23.10
VSCode Version: 1.128.0
Commit: e5c99d77d20a6f86647a0a257b866dfe9b116980
Quality: stable
OS: macOS (darwin 27.0.0)
For AI issues: which model did you use?
Requested variant: Grok 4.7 Extra High Fast
Task slug offered in the session allow-list and passed explicitly: grok-4.7-xhigh-fast
Agent file pin: grok-4.7[effort=xhigh,fast=true]
Earlier pin, before the context setting was removed: grok-4.7[effort=xhigh,fast=true,context=500k]
A different allow-list entry, cursor-grok-4.6-xhigh-fast, was not the requested model.
For AI issues: add Request ID with privacy disabled
Not captured. The failure is returned as a Task tool error before the subagent starts, and no Request ID was shown in the parent chat.
Additional Information
What this rules out:
- Not a bad prompt. The call fails before the subagent starts, and the error names the model id.
- Not context=500k. The explicit slug still fails after that setting is removed.
- Not “model missing from the picker.” grok-4.7-xhigh-fast is in the Task tool’s allowed list for the session. The registry then rejects the parameters attached to grok-4.7.
Agent files involved: ~/.cursor/agents/implementer.md and ~/.cursor/agents/reviewer.md.
Date observed: 2026-10-01.
Does this stop you from using Cursor
No - Cursor works, but with this issue