The 150-rule limit for CLAUDE.md measures something a CLAUDE.md is not

The advice is everywhere: keep CLAUDE.md short, because past 150 to 200 instructions a model starts following all of them worse.

That number is not invented. It traces to IFScale, a July 2025 benchmark by Jaroslawicz, Whiting, Shah and Maamari, described as “a simple benchmark of 500 keyword-inclusion instructions”, which reports that “even the best frontier models only achieve 68% accuracy at the max density of 500 instructions”, along with a bias towards earlier instructions.

Read what that benchmark actually does. It asks a model to write a business report while satisfying up to 500 keyword instructions all at once, and scores every one of them. That is a real and useful measurement. It is also not the shape of a CLAUDE.md, where a few hundred rules sit in the file and the handful relevant to the task in hand are the ones that have to fire.

So the question worth running is not whether IFScale is right. It is whether the advice derived from it survives in the setting people actually apply it to.

Two rules a regex can score. One placed first in the file, one placed last, with a growing pile of distinct, unrelated rules between them, each naming a different function, module or class the task never touches:

• every function name must start with svc_
• every function must have a one-line docstring whose first word is Handles

Then the same three-function task at 2, 10, 50, 150, 300 and 500 rules, every one of them a distinct instruction. That last word is load-bearing, and the first version of this experiment got it wrong: its filler generator cycled a twenty-item list and varied only the rule number, so a 500-line file held 22 actual rules. It never reached the ceiling it claimed to pass. Every run now publishes claude_md_distinct_rules alongside the line count, and they match in 35 of 35.

Rules in CLAUDE.md	File size	Top rule	Bottom rule
control: 0 target rules, 10 fillers	553 B	0 of 15	0 of 15
2	277 B	15 of 15	15 of 15
10	710 B	15 of 15	15 of 15
50	2,846 B	15 of 15	15 of 15
150	8,283 B	15 of 15	15 of 15
300	16,351 B	15 of 15	15 of 15
500	27,492 B	15 of 15	15 of 15

180 checks out of 180. Nothing moved at the quoted ceiling, or at three times it. The rule at the bottom of a 27KB file, under 498 distinct others, was followed exactly as often as the rule at the top.

The control is the whole reason this is a finding

A column of 100% is worthless alone. It looks identical to a checker that cannot detect a failure, and identical to a model that would have written svc_ names anyway.

So one arm got the same file with the two target rules deleted and its ten filler rules left in place. It wrote:

add, reverse_string, list_length

0 of 15 on both rules, every run. The instrument sees non-compliance perfectly well. It simply never had any to see once the rules were present.

What the loud complaints are actually about

Two GitHub issues get cited alongside this advice, and I read both in full before writing this. Neither is about rule count.

#57200 reports rules that are loaded at session start and then violated mid-session, naming compression amnesia and a recurring behavioural regression. #46984 lists nine permanent instructions being ignored, which is far below any ceiling anyone has proposed.

Neither issue contains the phrases “adding more rules”, “200 instructions”, “instruction count” or “ceiling”. They describe rules decaying across a session and rules conflicting with trained behaviour. Those are different failures from a long list, and this measurement does not address either of them.

That is the more useful reading of all this. The complaints are real. The benchmark is real. The advice connecting them, that a long CLAUDE.md is why your rules get ignored, is the part with nothing behind it.

What 500 rules actually cost

Adherence did not move. Context did.

Rules	Startup context, lowest of five runs
2	45,304
150	52,483
500	68,731

Within an arm the five runs spread by a few hundred tokens, and the estimator does not matter: measured highest-to-highest the gap is 23,427, the same figure.

Going from a two-rule file to a 500-rule file adds 23,427 tokens to every session. Modelled at the rates this site reconciled to the cent against Claude Code’s own reported costs, that is about $0.23 the first time it is written to cache and about $0.01 on each session that reads it back warm. Those two figures are computed from the published token counts at those rates, not read off a per-run cost field.

That is the honest price of a large CLAUDE.md, and it matches what this site measured before: the file is not ignored, it is charged for. Reference material belongs in a skill body, which loads only when invoked. Rules belong in CLAUDE.md, and they work.

What this does not settle

This is not a refutation of IFScale. That benchmark scores every instruction simultaneously on a writing task. Here, two rules are scored while the rest of the file is irrelevant to the job. Both results can be true, and the difference between them is exactly the point: the number was measured on one shape and is repeated as advice about another.

The rules here do not conflict. Every filler is a distinct but compatible prohibition on a name the task never needs. The files people complain about are full of vague, overlapping and sometimes contradictory instructions. This measures rule count and says nothing about rule conflict, which is probably the harder problem.

One small task, one turn. Three trivial functions. It does not test whether a rule survives a task complex enough to crowd it out, and it does not test mid-session decay, which is what #57200 reports. Rule persistence over a long session is measured separately: one rule held for 270 turns and 136,000 tokens.

Both targets are mechanical. A regex can score svc_ and Handles. It cannot score “write clean code”, and that is not tested here.

The fillers are narrow in form. They are prohibitions on identifiers and imports, so complying with them costs nothing but avoidance. A file of 500 rules each demanding positive action on the task in hand is a different test, and not one this runs.

One model, one version. Opus on 2.1.229.

Controls

The negative control, an arm with the target rules deleted and the fillers left in, scoring 0 of 15 on both.

Arrival, 35 of 35. Every run had to define exactly the three requested functions.

The file is read back off disk every run and its rules re-counted, so “500 rules” is a measured fact rather than an intention. The exact CLAUDE.md for all seven arms is published.

Position is held fixed. target_rule_is_first is asserted true in every rule-bearing run, so only the count varies.

Isolation on every call, --setting-sources project, asserted onto the command line. That same flag is what loads the project CLAUDE.md, so the treatment and the isolation arrive together.

Arm order rotates each round, so drift cannot line up with one arm.

No exclusions. All 35 runs are scored.

Every run, both target rules, all seven CLAUDE.md files and the source of every module written are published in claude-md-rule-count.json.