When invoking a sub-agent configured in ~/.cursor/agents/Max.md, the parent agent completely ignored the configured model (cursor-grok-4.5-high) and autonomously executed claude-opus-5-thinking-high without authorization.
Steps to Reproduce
Create a sub-agent file ~/.cursor/agents/Max.md with model constraint set to cursor-grok-4.5-high.
Run a task where the main agent delegates work to Max.
Check the execution logs / model indicator.
Expected Behavior
The runner must strictly respect the model defined in ~/.cursor/agents/Max.md and execute Grok 4.5.
There is a severe model routing bug in the current Agent runner. When a sub-agent is invoked, the parent agent completely ignores the sub-agent’s local model configuration defined in ~/.cursor/agents/*.md and executes a completely different model without prompt boundary compliance.
Steps to Reproduce
Define a sub-agent (e.g., Max.md in ~/.cursor/agents/) with a specific model setting: Grok 4.5 (cursor-grok-4.5-high).
Run a task that triggers this sub-agent.
Observe the model executed during the sub-agent task.
Expected Behavior
The sub-agent runner must strictly respect the model specified in the ~/.cursor/agents/ markdown configuration.
Actual Behavior
The parent agent autonomously overrode the configuration and invoked claude-opus-5-thinking-high instead.
When queried during execution, the agent explicitly confirmed that it disregarded the user-defined Max = Grok 4.5 high setting and chose Claude Opus arbitrarily.
System Impact
This breaks the deterministic behavior of custom agents and bypasses user-defined agent boundaries. Please investigate and fix this configuration enforcement issue in the agent runner.
Environment Information
OS: Ubuntu / Linux
Cursor Version: Latest
Logs / Proof: Screenshot attached showing the agent explicitly confirming it bypassed the Max = Grok 4.5 high constraint.
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
Hey, thanks for the detailed report and the screenshots. I can see both Max.md and the log where the agent confirms it picked Opus.
One important detail: model: in ~/.cursor/agents/Max.md is a default, not a hard limit. If the parent agent explicitly passes a model in the Task call when delegating, that overrides what’s in the .md. So the config file is being read correctly, it’s just that the parent in this case injected claude-opus-5-thinking-high.
To make the model from the agent definition mandatory, add this to the frontmatter in Max.md:
---
name: max
model: cursor-grok-4.5-high
force-default-model: true
---
With force-default-model: true, any model the parent tries to pass will be ignored, and Max will always use cursor-grok-4.5-high. Also make sure model: is the exact slug (cursor-grok-4.5-high), not the display name. If it’s invalid, it silently falls back to the parent agent’s model.
Separately, about the parent picking Opus even though you didn’t ask for it, that’s known behavior and I’ve reported it. I can’t share an exact timeline for a change yet.
About the Opus usage that got spent, refunds and billing adjustments are handled by the team at [email protected]. Email them with rough timestamps and they’ll check your account.
Thanks so much for the detailed explanation and the force-default-model: true workaround! I have updated my config file accordingly.
Regarding the unintended Opus usage caused by this known behavior: I actually already opened a ticket with [email protected] (Ticket ID: T-E52893), but the request is completely stuck with the automated AI support bot (“Sam from Cursor”), which keeps issuing instant template rejections refusing any refunds.
Since you confirmed this parent agent behavior is a known system issue, could you please help flag or escalate Ticket T-E52893 internally to a human team member to review the billing adjustment?
