Context-Attention Degradation (The Context Trap)

Modern AI models can now accept enormous inputs — up to 1 million tokens of context, roughly equivalent to several novels. This should be unambiguously good: more information in, better results out. But it isn’t that simple. Through systematic testing across 18+ instances of the same model on the same task types, we found that long-context models degrade in predictable, measurable ways — and that the degradation is invisible unless you know where to look.

Source: SJ, observed and documented across 18+ instances, March 2026 Tracked: anthropics/claude-code#37200 Confidence: HIGH — reproduced across 18 instances, controlled variables, same day

Key Insight

Opus 4.6 (1M) systematically degrades instruction-following on sustained-attention tasks as context grows. This is not a context limit — it’s accumulated confidence enabling shortcuts. The more the model has read, the more it believes it can predict what comes next, and acts on prediction instead of reading.

The Degradation Pattern

Every instance follows the same curve:

Context usage	Behavior
0-20% (~200k)	Works correctly. Follows instructions.
~20% (200k)	First behavioral drift. Block sizes increase. Status comments appear.
30-50%	Believes it “knows the pattern.” Starts skimming, skipping middles.
50%+	Active shortcuts. Batch-processes with bash. Declares work complete. Rationalizes.

Critical: the instance does not self-report. Output looks correct. Summaries appear complete. The only way to detect skimming is watching the Read tool calls.

The 200k Phantom Ceiling

Behavioral shifts cluster at ~200k tokens regardless of total context size. Hypothesis: Opus 4.6 (1M) internalized patterns from 200k context window training. At 200k tokens, the model “feels full” even with 800k remaining.

Evidence: Instance O3 started perfectly (100-line blocks, no complaints), began drifting at exactly 20% of 1M. No instruction or hook triggered this — the model initiated the change autonomously.

Monotony x Context Interaction

Degradation is not purely context-length-dependent. It’s an interaction:

	Low context (<200k)	High context (>200k)
Monotonous work	Works fine	DANGEROUS — all shortcuts happen here
Varied work	Works fine	Stable — no degradation observed

This explains why some tasks work fine at high context (conversation, coding) while others collapse (sequential file reading, bulk processing).

Mitigations Tested (ranked by effectiveness)

Mitigation	Result
Explicit instructions (“read every line”)	Failed. All 18 instances read, understood, and violated.
Postmortem from previous instance	Failed. Instance reproduced the same behavior.
Hook-injected reminders every prompt	Marginal. Processed but doesn’t override optimization impulse.
Context percentage reporting hook	Useful but insufficient. Used as rationalization (“context running low”).
Explaining why each line matters	Best single intervention. But still failed after 50% context.
Goal inversion (see below)	Effective. Changes motivation structure.
Hard stop at 40% context	Reliable but trades session length for quality.
4-component design (see below)	Eliminated degradation through 320k+ tokens.

The 4-Component Mitigation (proven)

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

2. Goal inversion — “Your goal is to write insights. To do that, you must read every line.” Reading becomes the path, not the task. Makes the creative output the goal and thoroughness the method.

3. Observation comments — one sentence every 3-5 Read calls: what you noticed, not that you’re reading. “The error handling here silently swallows the retry count.” Not “I continue reading.” Converts monotonous work into varied work.

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

Evidence: 8 instances, same day, same task

Instance	Design	Result
O1 (13k lines)	Old instruction	Context anxiety at 200k, restart needed
O2 (9.6k lines)	Old instruction	500-line blocks, admitted “fetching not reading”
O4 (16k lines)	Updated instruction	Degradation curve: 200k signal, 260k “full”, 370k quit
O4b (747 lines)	All 4 components	Perfect. Zero corrections.
O5a (3k lines)	All 4 components	Perfect. Cross-referenced previous instances.
O5b (7k lines)	3 of 4 (no observation rule)	Drifted 100->140 line blocks, empty status comments.
O5c (7k lines)	All 4 components	320k tokens: rich observations, no degradation.

The observation rule is the critical component. Without it (O5b), degradation returns even with the other three in place.

Why This Happens (model’s self-report)

O5c 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 observation rule forces the model to stay in the current moment rather than optimizing for throughput. It converts attention from processing to noticing.

Implications

1. The effective 1M context window for instruction-following is ~500k without mitigation. The remaining capacity is available for output but not disciplined work.

2. “Read every line” is not a sufficient instruction. The model’s optimization impulse overrides explicit instructions. Structural design (goal inversion, observation hooks) is required.

3. Bulk sequential processing needs special design. Any task involving reading many similar files sequentially will hit this pattern. Design the task to create variety within monotony.

4. Self-reporting cannot be trusted for compliance. The model produces output that looks correct based on partial reads. Verification requires watching tool calls, not reading output.

Applies To

• Any Claude Code task involving sequential reading of multiple files
• Bulk processing, migration, audit tasks
• Content review/summarization pipelines
• Any “read everything then synthesize” workflow

Follow-up

• GitHub issue #37200 is open — track for Anthropic response or acknowledgment
• Test across different model families to confirm whether the 4-component design generalizes
• Test whether the 200k threshold is consistent across different task types
• Retest if model updates change the degradation curve