.cursorrules vs copilot-instructions.md — We Tested Both on the Same Codebase for 30 Days and One Burned 3x More Tokens for Worse Results

Cursor's MDC system with 8 scoped rule files averaged 340 tokens of instruction overhead per request. The equivalent monolithic copilot-instructions.md with the same rules content averaged 1,054 tokens per request — 3.1x higher. The difference: Cursor's glob patterns ensured that only relevant rules activated. When editing a React component, testing rules and API rules stayed dormant. Copilot injected everything regardless. Over 30 days across 12 developers averaging 47 AI requests per day, the total token overhead was: Cursor = 5.8M instruction tokens, Copilot = 17.9M instruction tokens. At current API pricing, that's the difference between $14.50 and $44.75 in instruction overhead alone.

We tracked compliance across 4 rule categories: naming conventions (e.g., 'use camelCase for functions'), import ordering (e.g., 'external imports first, then internal'), architectural constraints (e.g., 'never import from server/ in client/'), and error handling patterns (e.g., 'always use Result types, never throw'). Simple formatting rules: Copilot 92%, Cursor 87%. Complex architectural rules: Cursor 79%, Copilot 61%. The insight: Copilot's bigger instruction payload created noise that drowned out complex rules. Cursor's scoped rules had higher signal-to-noise, so the model paid more attention to each individual instruction.

Both systems showed a sharp enforcement degradation when total instruction tokens exceeded ~1,200. Rules at the bottom of the file were ignored 43% more often than rules at the top. This aligns with known LLM attention patterns — the 'lost in the middle' effect where models attend strongly to the beginning and end of context but lose focus in the middle. Copilot's monolithic file hit this cliff faster because all rules loaded simultaneously. Cursor's MDC system avoided the cliff for most interactions because each scoped rule file was individually small.

On complex tasks requiring 80%+ of the context window (large refactors, multi-file changes), instruction files became the compression target. Both Cursor and Copilot silently truncated instructions when the context filled — but Cursor's behavior was more predictable because fewer rules were loaded in the first place. Copilot's Agent Mode showed the most aggressive truncation: on tasks exceeding 24K tokens of code context, we observed copilot-instructions.md being partially dropped from the prompt 34% of the time. The AI was actively ignoring your configuration file on your most complex tasks — exactly when you need the rules most.

Each rule lives in its own .mdc file with YAML frontmatter: 'description' (agent-readable summary), 'globs' (file patterns that trigger the rule), and 'alwaysApply' (boolean for global rules). Example: a testing rule with globs: ['**/*.test.ts', '**/*.spec.ts'] only activates when editing test files. This means your React component rules don't consume tokens when you're writing API endpoints. The legacy .cursorrules flat file still works but is deprecated — Cursor's agent reads the 'description' field to decide relevance, adding another intelligence layer. Maximum recommended size: 500 tokens per rule file.

The primary file is a single Markdown document in .github/copilot-instructions.md — injected globally into every Copilot request. Copilot added scoped files in .github/instructions/*.instructions.md with YAML frontmatter supporting 'applyTo' glob patterns — structurally similar to Cursor's approach. However, adoption is lower because the feature shipped later and documentation is sparse. Most teams still use the monolithic file. The global file has no built-in size limit, but our testing shows enforcement degrades linearly beyond 800 tokens and falls off a cliff beyond 1,200.

Claude Code uses CLAUDE.md in the project root plus nested CLAUDE.md files in subdirectories. The subdirectory approach provides implicit scoping — rules in frontend/CLAUDE.md apply when working in the frontend directory. No YAML frontmatter, no glob syntax. The simplest system architecturally, but the least flexible for complex monorepos. Claude Code's 200K context window makes token overhead less critical — you have room. But attention degradation still applies: a 3,000-token CLAUDE.md file means Claude is paying less attention to your code regardless of how much window remains.

All three systems share the same fundamental limitation: they are static text files injected into a dynamic context window. They can encode naming conventions and simple patterns. They cannot encode cross-repository type dependencies, runtime API contracts, or dependency graphs that change with every commit. A .cursorrules file can say 'use the UserProfile type from shared/types.' It cannot say 'the UserProfile type currently has 14 fields, and fields 3 and 7 were added last week by a different team.' Static rules handle the 30% of context that never changes. The other 70% — your actual project state — requires dynamic context injection.