# Model-specific rules **URL:** \ **Category:** Feature Requests\ **Created:** [February 2, 2025, 9:57pm UTC](https://forum.cursor.com/t/model-specific-rules/47175 "2025-02-02T21:57:16Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![KamilTheDev](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kamilthedev/32/24672_2.png) [@KamilTheDev](https://forum.cursor.com/u/KamilTheDev)\ **Post date:** [February 2, 2025, 9:57pm UTC](https://forum.cursor.com/t/model-specific-rules/47175/1 "2025-02-02T21:57:16Z")
The new cursor rules system is great, it would also be good if we could have rules for specific models. ---
**Author:** ![MadeUpMasters](https://avatars.discourse-cdn.com/v4/letter/m/cdc98d/32.png) [@MadeUpMasters](https://forum.cursor.com/u/MadeUpMasters)\ **Post date:** [March 1, 2025, 12:03pm UTC](https://forum.cursor.com/t/model-specific-rules/47175/2 "2025-03-01T12:03:53Z")
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. ---
**Author:** ![normalnormie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/normalnormie/32/18258_2.png) [@normalnormie](https://forum.cursor.com/u/normalnormie)\ **Post date:** [March 3, 2025, 1:53pm UTC](https://forum.cursor.com/t/model-specific-rules/47175/3 "2025-03-03T13:53:36Z")
+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. ---
**Author:** ![AbleArcher](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/ablearcher/32/19439_2.png) [@AbleArcher](https://forum.cursor.com/u/AbleArcher)\ **Post date:** [March 16, 2025, 12:03am UTC](https://forum.cursor.com/t/model-specific-rules/47175/4 "2025-03-16T00:03:13Z")
+1 Being able to create and auto-attach model specific rules / custom instructions would be a nice improvement. (something like this) ![image](https://us1.discourse-cdn.com/cursor1/original/3X/1/9/19d05d12aab43349ea4e6ed30cca33c1cbc1bae9.png) ---
**Author:** ![amxv](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/amxv/32/6120_2.png) [@amxv](https://forum.cursor.com/u/amxv)\ **Post date:** [July 26, 2025, 7:48pm UTC](https://forum.cursor.com/t/model-specific-rules/47175/5 "2025-07-26T19:48:51Z")
+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. ---
**Author:** ![bstpierr](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/bstpierr/32/19849_2.png) [@bstpierr](https://forum.cursor.com/u/bstpierr)\ **Post date:** [August 8, 2025, 1:18am UTC](https://forum.cursor.com/t/model-specific-rules/47175/6 "2025-08-08T01:18:12Z")
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. ---
**Author:** ![fredatrespondent](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/fredatrespondent/32/58753_2.png) [@fredatrespondent](https://forum.cursor.com/u/fredatrespondent)\ **Post date:** [August 26, 2025, 12:27am UTC](https://forum.cursor.com/t/model-specific-rules/47175/7 "2025-08-26T00:27:02Z")
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 ---
**Author:** ![OmryA](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/omrya/32/110667_2.png) [@OmryA](https://forum.cursor.com/u/OmryA)\ **Post date:** [August 5, 2026, 10:05am UTC](https://forum.cursor.com/t/model-specific-rules/47175/8 "2026-08-05T10:05:11Z")
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](https://forum.cursor.com/t/custom-skills-or-rules-per-model/166332). - _Model routing_ — “run this rule’s work on model X.” That’s [Extend .mdc rule frontmatter with a `model:` field](https://forum.cursor.com/t/extend-mdc-rule-frontmatter-with-a-model-field-for-cost-efficient-agentic-workflows/156812) 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](https://code.claude.com/docs/en/sub-agents) 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](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/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`: ```auto models: [opus, sonnet] # ideally with negation / exclusion ``` Family-level matching would cover most cases and wouldn’t need updating on every model release.