claude-code - 💡(How to fix) Fix Opus 4.7 + xhigh effort + 1M context: 25-turn correction loop on a status query despite extensive user-side memory

The concern

Paying premium price for premium tier on premium context window, plus carrying the cost of maintaining extensive user-side scaffolding (80+ feedback memory entries built up over months), and the output still fails below the floor on basic comprehension. The scaffolding doesn't close the gap. This session is the receipt.

The session

Opened with "where are we at," a status query on my project (a daily OSINT pipeline).

Claude reported status (pipeline complete, working tree had post-run state churn, no processes active) and concluded "nothing requiring attention."

I quoted Claude's own words back: "nothing requiring attention". A bare-quote skeptical signal.

Claude immediately began action-prep tool calls (git check-ignore, git log on prior-day artifacts) toward cleaning up my working tree. I never authorized this.

I interrupted: "I didn't say to do anything."

What followed, billed at Opus 4.7 + xhigh + 1M context across ~25 turns:

• Defended the action ("no code changes were made") instead of acknowledging the action-prep being staged
• When asked why it moved to act, gave layered self-theorizing answers that themselves demonstrated the failure mode (treating turn-cost as a real constraint when memory explicitly says to ignore it)
• When asked for solutions, produced restated rules and called them solutions
• When pushed on that, proposed hooks
• When told hooks can't fix interpretation, folded with "no engineering solution, training-level property"
• When that fold was called defeatist, walked it back and proposed a CLAUDE.md rule, which is the same in-context bias mechanism as the memory that just failed
• When called out as same-mechanism-different-packaging, eventually acknowledged the whole session had been meta-diagnosis displacing real project work

What was already in place

User-maintained feedback memory at ~/.claude/projects/<project>/memory/ contains 80+ entries, including direct coverage of this exact failure pattern:

• feedback_diagnosis_vs_action
• feedback_no_obvious_confirms
• feedback_discuss_before_implementing
• feedback_execute_dont_reconfirm
• feedback_no_scrambling
• feedback_pressure_discipline
• feedback_plan_mode_discipline
• feedback_verify_before_speaking
• feedback_no_first_person
• feedback_dont_pad_corrections

All loaded in context. None prevented the failure.

What this tier should deliver

At Opus 4.7, xhigh effort, 1M context, with extensive memory scaffolding loaded:

• Skeptical bare-quote pushback should not be misread as authorization to act
• Correction should resolve in 2-3 turns, not 25
• When the model can't fix something, it should say so plainly, not propose the same broken mechanism in different packaging
• The session should not spend itself diagnosing the model instead of doing the user's actual work

What I'm asking for

1. Premium tiers should not fail below floor on basic intent comprehension. If they do, the pricing should reflect that.
2. Acknowledge that user-side scaffolding (memory, CLAUDE.md) doesn't close interpretation gaps. Stop pretending it does.
3. This session as training signal. A user with 80+ feedback memories hitting the same failure modes is high-value telemetry.