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.