I’ve seen a lot of advice floating around saying we should keep .cursorrules or .mdc files minimal — usually “under 10 rules” or “keep it short.”
I wanted to see if this was actually true for the current version of Cursor (Auto mode), so I ran two tests.
Test 1: Clean test file
Created 50 verifiable rules (semicolons, prefixes, no-console, etc.)
Ran the same refactoring task 18 times
Scaled up rule counts: 1, 5, 10, 20, 30, 50
Result: 100% compliance at every level, even at 50 rules
Test 2: Real codebase
Same 50 rules, but on an actual project (4 files, ~900 lines, multi-file refactor).
Result: 96-98% compliance. 1-2 rules silently dropped each run, different ones each time. No pattern I could find — wasn’t the vague rules or the long ones.
My takeaway:
50 rules works. The “keep it under 10” advice is wrong. But in a real project, rules are competing with your code for context, so you might lose 1-2 randomly.
If your rules aren’t firing consistently, check for:
Missing alwaysApply: true (huge factor in my testing)
Bad frontmatter syntax
Vague/conflicting instructions
Those structural issues are way more likely to cause problems than rule count.
I didn’t test above 50, so there’s probably a ceiling somewhere. If anyone’s running more than that I’d be curious how it holds up.
Hey, solid testing and write-up. The findings match how the system is designed. There’s no hard cap on the number of rule files. The main constraints are context window size, since rules compete with code for space, and rule quality.
A couple of additions from the docs side:
The recommendation is to keep individual rules under 500 lines and split big ones into focused, composable files. But the number of files itself isn’t limited.
Apply Intelligently rules, where alwaysApply: false and a description is set, let the agent decide whether to include a rule based on relevance. This is useful if you’re worried about context getting full at higher rule counts.
Referencing files with @filename instead of copying content into rules also helps keep context overhead low.
The part about 1 to 2 rules randomly dropping on real codebases is expected. Bigger code context means less room for rules, and the model may deprioritize some. Good call flagging alwaysApply, bad frontmatter, and vague instructions as the real culprits instead of rule count.
Thanks Dean, I appreciate your confirmation. The docs are useful. The @filename referencing tip is one I hadn’t considered for keeping context overhead down at higher rule counts.