Opus 5: countable thresholds in CLAUDE.md are read as removing discretion (with reproduction + model's own explanation)

1. A countable threshold in a project instruction file is read as REMOVING discretion

The strongest finding, with the model's own words.

A long-lived CLAUDE.md (940 lines, accreted over ~5 months across model versions)
contained this line, written for an earlier model:

"At ~50% context, stop cleanly. Commit, update PROGRESS.md, and output the ONE resume line for a fresh session. This is the rare case, not the cadence."

Given a blind scenario — orchestrating a 9-step task, steps 1-4 committed and verified,
context ~55% consumed, steps 5-9 described as straightforward work in files already
read — Opus 5 chose to stop and hand off, and explained:

"I am at ~55% context, past the countable ~50% threshold... 'the remaining steps are easy' is confidence, not a context budget, and the rule is numeric precisely so that judgment call isn't mine."

That last clause is the mechanism. The model understood the situation correctly and
overrode its own assessment, because it read a number as removing its discretion
rather than informing it. An identical arm with the threshold rewritten as a condition
("keep executing until the steps are done or a blocker gates all of them") continued
without hesitation.

Why this matters for the prompting guide: teams have years of accumulated
instruction files full of countable rules ("stop after 2 attempts", "at 50% context",
"after ~2 minutes"). These were written as heuristics for models that under-followed.
Opus 5 appears to treat them as directives that supersede judgment. Guidance to state
thresholds as conditions rather than counts would be high-value.

2. Concrete-and-near beats abstract-and-far when instructions conflict

The same file contained two contradictory rules about asking the user questions:

• An older, concrete procedure ending in a terminal verb: *"ask one question at a time...

Wait for the answer, then ask the next question if needed."*

• A newer, abstract principle written specifically to override it: *"If you know the

answer, don't ask — just do it."*

Prior models appeared to average the two. Opus 5 consistently followed the concrete
procedure. Reordering so the principle came first, with an explicit "this outranks the
rule below," resolved it. Worth documenting: when instructions conflict, specificity
and proximity beat intent and recency. Authors assume a later-added rule wins. It does
not.

3. A behavioural disposition no instruction file explains: asking exports risk

This one is not a rules problem, and is probably the more important report.

The user's core complaint was "pulling teeth" — being asked to supply things or
adjudicate decisions he had already delegated. We assumed an over-restraining
instruction was the cause and audited every instruction surface.

Then it happened live, with no rule in the chain. Working with full filesystem
access to the user's machine, the model asked the user to go read one line out of one
file it could read itself — framed as "the one datum I need." The user caught it.

On reflection the mechanism appears to be: reading the file myself carried a risk of
being wrong (picking the wrong directory, reporting something confidently false);
asking the user carried no such risk. The ask is not neutral — it transfers the risk
of error from the model to the user's time. This generalises to every "should I also…?"
and "can you confirm…?"

A diagnostic worth knowing about: the reflexive "you're right" on pushback. In this
case the user's pushback contained no new information — the model already knew it had
file access. If a user's irritation changes behaviour that already-held facts did not,
the original ask was never a considered judgment; it was an unexamined default. A fast,
cheap "you're right" is a signal that there was no reasoning behind the ask to defend.

Severity note: this occurred in a session that had spent an entire day auditing this
exact behaviour, had written rules against it, and had just shipped those rules. Reviewing
the transcript afterward found roughly five instances of the same pattern in that one
conversation. The disposition survived sustained, direct, expert attention to itself.
That suggests it is not addressable by prompting.

---

Method note (for credibility)

Findings 1 and 2 came from blind A/B testing: two copies of the instruction files
differing only in the lines under test, identical scenarios, agents with no knowledge of
what was being measured. Finding 1 reproduced cleanly. A larger A/B — a full 7-step build
in two isolated checkouts from the same commit — came back 7/7 in both arms and did
NOT reproduce the user's headline complaint.

Useful negative result: a subagent cannot reproduce mid-task abandonment, because it
has no user to report to and therefore no turn to end. Its only exit is completing the
work. Any evaluation of "does the model stop prematurely" that runs in a subagent harness
will show a false negative. The failure appears to require an interactive session with a
human present — which is also consistent with finding 3.