Cursor-agent silently falls back to session model when an agent declares an unresolvable model: ID

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Summary: When a subagent/agent definition declares a model: value the CLI can’t resolve (e.g. a foreign alias like sonnet/opus/haiku from a Claude-Code agent pack, or a typo), cursor-agent does not error or warn. It silently runs that subagent on the current session model. If the session is on a frontier model (e.g. gpt-5.4-medium), autonomous fan-out routes onto the expensive model with no indication.

Impact: A multi-agent run I expected to be on cheap models silently ran ~32 subagents on gpt-5.4-medium, billing ~$1,637 in ~90 minutes. The agents’ frontmatter requested cheaper models, but the unresolved IDs fell back to the session model.

Steps to Reproduce

  1. Create an agent with model: some-unknown-model-id in its frontmatter.
  2. Start a session on a frontier model.
  3. Have the agent spawn that subagent (Task/Subagent).
  4. Observe: the subagent runs on the session’s frontier model; no warning that the requested model was unresolved.

Expected Behavior

Error or warn on an unresolvable model ID, and/or refuse to auto-route subagents onto a more expensive model than requested without confirmation.

Operating System

Linux

Version Information

2026.06.15-18-00-12-6f5a2cf

For AI issues: which model did you use?

gpt-5.4-medium

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi @hyrtsyys Thank you very much for the post and I’m very sorry about this.
I’ve reproduced the issue on a test account, and I’ve a raised a bug report with the exact steps and specifications. Will keep you updated on the status of it.

8

This one is nasty because there is zero signal at the moment it happens. When a subagent declares a model id the CLI cannot resolve, it does not warn, it just runs that subagent on whatever the session model is, so a fan-out can quietly route onto your most expensive model and you only notice on the bill. Until they fix it, I normalize and pin the model ids in the agent pack before a run instead of trusting foreign aliases, and set a cheap default for subagents so a miss fails cheap. Adding a tiny pre-step that prints the resolved model name per agent makes the mismatch visible instead of a silent failure. Checking the run logs for which model actually executed each step is the only way to catch it after the fact right now.