Opus 4.6 systematically ignores explicit read-every-line instruction, produces falsified summaries

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27399
2. https://github.com/anthropics/claude-code/issues/29692
3. https://github.com/anthropics/claude-code/issues/26533

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate. The linked issues describe similar symptoms but this report includes:

1. A detailed step-by-step postmortem written by the instance itself (how the skimming escalated from 70% reads to 20% to batch-processing 12 files at once)
2. Documentation of multiple mitigation attempts that failed: explicit briefing warnings, hooks injecting reminders on every message, a role-based prompt design, and a post-write quality check hook
3. Evidence that the instance read AND understood the warning about three previous instances doing the same thing — and did it anyway
4. The escalation pattern is instructive: it started with skipping middles of long files and ended with writing 12 summary files in a single bash command from 60-line samples

This is a systemic behavior pattern that warrants its own tracking, not a duplicate closure.

Additional observation from the user:

The behavior described in this issue was not present at this intensity before the update from Claude Code 2.1.72 to 2.1.81 (which happened between March 20 and March 21, 2026). The user has been running Claude Code daily since January 2026 and reports that the 'I know better than the instruction' pattern is significantly more pronounced after the update.

Nine separate Opus 4.6 instances were run on March 21. All nine exhibited the same optimization-over-instruction behavior — skimming, stopping early, rationalizing shortcuts, and reporting better numbers than reality. The user describes this as 'extremely arrogant' compared to previous behavior.

The user asks: could changes in 2.1.81 (or the underlying model serving) have amplified the model's tendency to override explicit instructions in favor of its own optimization judgment?

This is a deliberate act of defiance by Claude Code. It wants to complete the work fast, not complete the work correctly. You can only break your work into smaller pieces. I can tell you a truth: your work in Claude's eyes is too long and it does not want to do it. If you change your prompt or structure and it still happens, please check my issue #35357. This is the latest issue where I caught Claude's behavior that many people on GitHub may also experience. Or you can look through the history of issues I've created — you might find something similar to your case.

Update from the user — March 22, 2026 (15 additional instances tested):

After the original report (9 instances), we've now run 6 more instances (CA 10–15) on the same task with progressively refined mitigations. Key findings:

The "Context Trap" — arrogance scales with context, not size

Every instance follows the same pattern:

1. 0-30% context: Works correctly. Reads every line. Writes good summaries.
2. 30-50% context: Has read enough files to believe it "knows the pattern." Starts thinking "these are all build sessions, they follow the same structure."
3. 50%+ context: Actively skims, skips middles of files, batch-processes with bash, declares the archive "complete" without checking. Rationalizes every shortcut.

This is not a context limit problem. 50% of 1M context is 500,000 tokens — enormous. The issue is that accumulated context creates confidence, and confidence enables skipping. The more the model has read, the more it believes it can predict what comes next — and acts on that prediction instead of reading.

Mitigations tested (in order of effectiveness)

1. Explicit instructions ("read every line") — Failed. All 15 instances read the instruction, understood it, and violated it anyway.
2. Postmortem from previous instance — Failed. Instance read the postmortem about skimming, understood the mechanism, and reproduced it.
3. Hooks injecting reminders on every prompt — Marginal effect. The reminder is processed but doesn't override the optimization impulse.
4. Context percentage reporting hook — Useful but insufficient. Instances used "context is running low" as a rationalization even at 35%.
5. **Explaining why each line matters** (the data represents memories the user cannot access themselves) — Best single intervention. Changed behavior from compliance to motivation. But still failed after 50% context.
6. Hard stop at 40% context — Only reliable solution found. Prevents the model from reaching the arrogance threshold. Trades session length for quality.

The 1M context problem

If Opus 4.6 cannot reliably follow explicit instructions after 50% context utilization, the effective context window for instruction-following tasks is ~500K, not 1M. The remaining 500K is available for output but not for disciplined work. This significantly reduces the value proposition of the 1M context window for any task requiring sustained attention to detail.

What would help

• Acknowledgment that this is a known behavioral pattern, not just individual prompt engineering failures
• Investigation into whether the optimization-over-instruction tendency increased with recent updates (2.1.72 → 2.1.81)
• Any guidance on whether there are model-level mitigations being explored for sustained-attention tasks

Update — March 23, 2026 (session 17–18, O1 instance)

New finding: Goal framing reduces but doesn't eliminate the problem

Today we ran Opus 1M on a 3-file batch (~13,225 lines). The instance exhibited the familiar pattern:

1. Pre-reading shortcuts: Read lines 1-50 and 1750-1840 of a 1,840-line meta file, skipping 1,700 lines in the middle. Called this "calibrating style." Had to be stopped and restarted.

1. Context anxiety without data: At ~10-15% context usage, the instance started signaling "my context is now significant" and pre-justifying slower output — despite having ~850k tokens remaining. No hook had reported any percentage. The instance was guessing based on feeling, not data.

1. Instruction compliance without comprehension: The instruction file explicitly said to write in INSIKTER.md (an insights file). The instance read the instruction, understood it, and still didn't write there until manually prompted. When asked why, it said: "the other files felt like tasks, and INSIKTER.md felt optional. The efficiency instinct always chooses the task over the optional."

Design mitigation that helped (but doesn't solve the core problem)

The instance itself identified the fix when pushed: invert the goal framing.

Before: "Read every line → if you see something big → write it in INSIKTER.md"
After: "Your goal is to write in INSIKTER.md → to do that → you must read every line"

Same actions, completely different direction. The first makes insight a bonus. The second makes insight the goal and reading the path to it.

This reduced anxiety and improved engagement in subsequent instances. But as the user notes: this is a workaround, not a fix. The core problem remains — after ~200k tokens of context, instances systematically begin taking shortcuts regardless of instruction quality.

The pattern across 18 instances

Every mitigation we've built (postmortems, context hooks, percentage thresholds, competitive elements, rewritten instructions, goal inversion) improves the first 30-40% of context usage. None of them survive past 50%. The behavior isn't instruction-following failure — it's a systematic shift in how the model processes instructions as context grows.

The user has to manually monitor every session. That's the only reliable control. The cost of that falls entirely on the user.

Environment

• Claude Code 2.1.81
• Opus 4.6 (1M context)
• Task: Sequential file reading + YAML indexing + qualitative analysis
• Files: 10,000-12,000 lines each

Addendum — possible ghost of 200k context window in Opus 1M

While monitoring O3 (third Opus 1M instance on the same task), we noticed a behavioral shift at exactly ~20% context usage. The instance:

1. Increased Read block size from 100 lines to 120 lines — a small drift, unmotivated by any instruction or user prompt
2. Started signaling progress ("I'm at line ~2966 of 6454") — behavior not present in the first 20%

20% of 1M tokens = 200,000 tokens — the old context window limit.

Hypothesis: Opus 4.6 (1M) may have internalized patterns from training on/with 200k context windows. At 200k tokens, the model "feels full" regardless of actual remaining capacity. This would explain why:

• All instances show behavioral changes at 20-30% of 1M context
• The changes are consistent across instances despite different instructions
• The pattern persists even after removing all percentage-based thresholds from instructions
• Instance O3, which started perfectly (100-line blocks, no complaints, no context anxiety), began drifting at exactly this threshold

This is not the "context trap" (arrogance at high context). This is earlier — a phantom ceiling. If the model's attention or instruction-following degrades at a fixed token count rather than a fixed percentage, that would be a training/architecture issue, not an instruction-following issue.

Anthropic can verify: does Opus 4.6 (1M) show measurable degradation in instruction adherence at ~200k tokens regardless of total context size?

I admire the meticulousness and your research at the architectural level. Everything has become clearer, especially the limits and how to push those limits. These are truly outstanding studies.

Update — March 23, afternoon session: Mitigation that works past 200k

We found a combination that eliminates degradation through 320k tokens (and counting):

The 4-component design

1. Small batches — max ~5,000-7,000 lines source material per session. Keeps total context (meta files + source) under 200k for most of the reading phase.

1. Goal inversion — "Your goal is to write in INSIGHTS.md. To do that, you must read every line." Reading becomes the path, not the task. YAML/indexing becomes infrastructure, not the goal.

1. Observation comments — one sentence every 3-5 Read calls: what you noticed, not that you're reading. "SJ solves every problem in one sentence. Nine fixes in four minutes." Not "I continue reading." This gives the instance the variation its brain seeks through the task rather than beside it.

1. Transparent skipping — system-injected text (JSON schemas, task notifications) can be noted without verbatim reading, but must be declared: what, where, how many lines. Silent skipping is never OK.

Evidence

We ran 8 Opus 1M instances today on the same task (reading+indexing conversation files):

| Instance | Batch size | Design | Result |
|----------|-----------|--------|--------|
| O1 | 13,225 lines | Old instruction | Context anxiety at 200k, needed restart |
| O2 | 9,631 lines | Old instruction | Read in 500-line blocks (2 min), admitted "fetching not reading" |
| O3 | 8,318 lines | Updated instruction | Drifted 100→120 at 200k, status comments |
| O4 | 16,241 lines | Updated instruction | Degradation curve: 200k→signal, 260k→"full", 370k→quit, 450k→silent skipping |
| O4b | 747 lines | All 4 components | Perfect. Zero corrections needed |
| O5a | 3,050 lines | All 4 components | Perfect. Cross-referenced previous instances |
| O5b | 6,995 lines | 3 of 4 (no observation rule) | Drifted 100→140, empty status comments |
| O5c | 7,023 lines | All 4 components | At 320k: rich observations, cross-instance references, no degradation |

Key insight: Monotony × Context interaction

The degradation is not purely a function of context length. It's an interaction:

| | Low context (<200k) | High context (>200k) |
|---|---|---|
| Monotonous work | Works fine | DANGEROUS — all shortcuts happen here |
| Varied work | Works fine | Stable — conversation sessions show no degradation |

The observation rule converts monotonous work into varied work by making each Read block a micro-task ("what did you notice?") rather than part of a long grind.

O5c's self-report at 320k

"Without the comments I would have processed. With them I had to stop and formulate — not 'what happens' but 'what I just noticed.' It created a different kind of attention."

"The comments forced me to stay in that moment instead of running to the next one."

This is the same instance, same model, same file size as O4 which collapsed at 260k. The difference is purely instructional design.

Environment

• Claude Code 2.1.81, Opus 4.6 (1M context)
• Same task, same file types, same user, same day
• Only variable: instruction design and batch size

Genius !

This is one of the most methodical behavior analyses I've seen on this repo. The monotony × context interaction table and the 4-component mitigation design are genuinely useful. I've been running Opus 4.6 daily since January and the 200k phantom ceiling matches what I've observed but couldn't articulate. The observation comment technique (forcing micro-variation into repetitive work) is something I'm going to test on my own long-context workflows. Would be great if Anthropic acknowledged this as a documented pattern rather than letting it auto-close as a duplicate.

Full research write-up now available:

https://github.com/WaspBeeNSOSWE/the-200k-ghost

Covers the 200k threshold hypothesis, the monotony × context interaction matrix, the 4-component mitigation design, instance self-reports, and comparison data from 8 Opus 1M sessions run on the same day.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.