I keep seeing people say they switched to a more expensive model because the cheap one “kept ignoring rules.” I ran some tests on this and I don’t think the model is the problem.
I used the same .mdc rules, different models, same prompts. worked the same. the cheap model followed the rules just as well.
turns out what broke things in my tests: missing alwaysApply: true in the .mdc frontmatter (rule just doesn’t load without it), vague prompts that don’t give the model enough to work with, and .cursorrules conflicting with .mdc files silently.
basically every time it looked like “the model is ignoring my rule,” the rule wasn’t even reaching the model. check your frontmatter, you don’t need to spend a bunch of money on tokens you don’t need.
And here is the job for Cursor to make an easy way for you to quickly and transparently observe exactly what reaches your LLM in the current request, how much tokens spent for each segment, etc.
I tested the rules with the most basic tests I could imagine, one at a time. It was inconsistent. I think it is more likely support for rules has improved than there was never an issue in the first place. If it is truly reliable now, that would be an improvement.
yeah this would solve half the debugging. right now if a rule isn’t loading you have no way to tell from the UI. you just see the model “ignoring” it and assume the model is the problem. some kind of “context inspector” that shows what rules were included in the request would save people a lot of wasted upgrades.
i just ran through every way i could think of to break .mdc rules. out of 7 things i tried, only 2 silently fail: malformed YAML (missing the closing ---) and having no frontmatter at all. everything else loaded fine, even alwaysApply: false which i didn’t expect. the frustrating part is both failures are completely silent. no warning, no error, the rule just doesn’t exist. so if your frontmatter has a typo you’d never know unless you checked the output carefully.