The new cursor rules system is great, it would also be good if we could have rules for specific models.
With the introduction of 3.7 Sonnet this is more needed than ever. 3.5 is working incredibly well so I don’t want to mess with it, but 3.7 goes off the rails all the time, I need to add a lot of additional rules to keep it constrained, but don’t want those applied to Claude 3.5 or anything else.
+1 we need to be able to specify different rules for different models, models don’t know about themselves so we need a section like it was done for “project rules” and a new directory like .cursor/rules/models to store them.
+1. This is going to be even more important with the new auto mode (which is already available for background agents on web, and its coming to the IDE soon)
Auto mode + background agents is basically unlimited AI coding without rate limits on Cursor pro+/ultra plans so it’s super important to write instructions differently for each model.
With GPT-5 being so shy about continuing to solve problems, I’d love to add a rule to nudge it to keep going, but this will most-certainly have unintended negative consequences with other models.
Echoing that this is so much more needed with GPT-5.
It’s great that it only does what you tell it to, but I would like to nudge it to consider the big picture way more often
Adding a data point and a small correction, because this thread and the newer ones are quietly asking for two different things.
Two different asks
- Conditional activation — “apply this rule only when model X is answering.” That’s this thread, and Custom Skills or Rules per Model.
- Model routing — “run this rule’s work on model X.” That’s Extend .mdc rule frontmatter with a
model:field and the various Commands model-selector requests.
Subagents already solve the second one through their model: field, and that’s what staff suggested on 156812. They don’t solve this one: pinning which model runs a delegated task is not the same as conditioning instructions on which model is already running. Worth keeping the two separate so the routing answer doesn’t get read as closing this request.
Frontmatter never reaches the model
I tested this by planting a rule with a custom model: key and then inspecting what actually landed in context. Always-applied rules are injected as the raw markdown body only — the --- delimiters, description, alwaysApply, and any custom keys are all stripped. So a custom key isn’t merely unsupported, it’s inert: the model can’t see it even to honour it voluntarily.
That leaves two prose-level workarounds, both self-policed: put the condition in the description (which gates whether the body gets loaded at all), and/or repeat it as a self-check in the body. Contrary to #3 above, models can self-gate — Cursor puts the model identity in the system prompt (“You are … powered by Opus 5”), so a model can read who it is. It just isn’t enforceable, and the always-applied variant burns tokens on every single turn for models that will end up ignoring it.
Prior art: Claude Code already has this in frontmatter
Claude Code’s skill frontmatter reference lists a model: field (“model to use while the skill is active”), alongside effort:, and subagent frontmatter accepts sonnet / opus / haiku, a full model ID, or inherit. Cursor has this for subagents only — not for rules or skills. Same file format, same idea, one axis short.
Why this matters more with current frontier models, not less
Anthropic now ships model-specific prompting guidance that is subtractive. Prompting Claude Opus 5 and the migration guide say to remove verification / “check your work” instructions carried over from earlier models, because Opus 5 self-verifies and leaving them in causes over-verification; to re-tune length and verbosity prompts because it writes longer by default; and to cap subagent spawning because it delegates more readily than earlier models.
In a single-model harness you simply delete those lines. In Cursor you can’t — rules are shared across every model you switch between, so guidance that is correct for one model actively degrades another. There is no way to express “drop the verification nudge for Opus 5, keep it for the older and cheaper models.” As frontier models diverge in behaviour, one global rule set gets strictly worse over time.
The ask
A fourth activation axis alongside alwaysApply / globs / description:
models: [opus, sonnet] # ideally with negation / exclusion
Family-level matching would cover most cases and wouldn’t need updating on every model release.