Context
The context window is capacity, not a quality guarantee.
A coding agent can begin a session sharp, then quietly start missing decisions, reopening settled questions, or claiming a test passed when it did not. Matt Pocock of AI Hero calls this slide the dumb zone. The label is memorable. The diagnosis needs more care: there is no universal token count at which every model becomes unreliable, and context length is only one possible cause.
Capacity is not reliable use
A large window can hold more than a model can use well
A context window is a capacity limit: the amount of input and output the model can accept in one request. Effective context is the evidence it can use reliably for a particular task. Those are not the same thing. A fact may fit inside the window yet still be overlooked, outweighed by stale instructions, or lost among similar tool results.
Research gives us a more useful picture than a fixed 100K frontier. Lost in the Middle found that performance changed with the position of relevant information. RULER found that longer and more complex tasks exposed weaknesses that simple retrieval tests missed. The practical boundary therefore moves with the model, task, evidence placement, noise and reasoning required. The curve below is a useful warning, not a measured law.
Effective context is workload-specific
Token count is only one input. Reliability also changes with the evidence and the job the model must do.
- Capacity Can the request fit inside the model's documented window? Necessary, not sufficient
- Composition Are the relevant facts fresh, authoritative and easy to distinguish from noise?
- Placement Can the model locate the evidence where it appears in the request?
- Task demand Retrieval, comparison and multi-step reasoning stress context differently.
- Controlled probe Compare the long session with a focused baseline on the same questions.
Measure the task. Do not invent a universal token cliff.
What a bigger window buys
More room is valuable, but it is not a quality guarantee
As of 13 July 2026, Anthropic documents a one-million-token context window for Claude Opus 4.8. The same documentation warns that accuracy and recall can degrade as token count grows. Both statements can be true. A larger window can keep a codebase map, long document set or extended conversation available. It does not promise equal attention to every token or dependable reasoning across the whole collection.
Think of the advertised window as the room available, then measure how well your workload uses it. A focused slice is often easier to reason over, but retrieval, continuity and long-document work can genuinely benefit from extra capacity. That distinction is why I resist treating the whole window as usable budget. The diagram below captures the distinction without inventing a fixed smart-zone size.
Advertised capacity versus proven use
A one-million-token window describes what can be accepted, not a promise of equal attention across every workload.
Documented capacity
- Up to 1M tokens Current Opus 4.8 documentation
- More continuity Useful for long documents, code maps and extended sessions
- More available evidence Relevant material can remain in one request
capacity is not quality
Reliability still needs testing
- Recall can vary Position and similarity can change retrieval
- Noise can compete Stale instructions and repeated tool output can obscure evidence
- Reasoning demand matters Complex synthesis can fail even when facts fit
Use the full room when it helps, then verify the specific work.
Diagnose before you reset
Test the session against a focused baseline
Token count alone cannot tell you whether context caused a mistake. Use a small, repeatable context probe. Ask the current session to restate the goal and non-negotiables, locate three named decisions or source files, and explain the expected result of one deterministic test. Do not let it edit yet. Record what it gets right.
Then run the same probe in a fresh session supplied only with a compact brief, the relevant plan, the current diff and the failing test. If that focused baseline recovers the missing constraints, poor context composition is a plausible contributor. If both sessions fail, inspect the specification, prompt, model, tool output and environment instead. This comparison does not prove causation, but it is much stronger evidence than watching a token meter.
Capacity tells you whether the request fits. A controlled probe tells you whether this model can still use the evidence reliably enough for this task.
A worked example
Recover the evidence, not just a fresh chat
Imagine an agent implementing subscription cancellation. The approved plan requires soft deletion and exactly one audit event. After a long run of logs, diffs and test output, the agent proposes a hard delete and omits the event. The probe asks it to name both constraints, inspect the cancellation test and describe the next patch. The long session misses the audit rule. A fresh, focused session supplied with the plan excerpt, current diff and failing test identifies both.
That result suggests context contributed; it does not reveal a magical threshold. Pause edits. Write a checkpoint containing the goal, decisions, changed files, failing test and unresolved question. Start fresh with only that checkpoint and the primary evidence. Make the narrow correction, run the focused test, then the wider suite, and review the diff. This is the practical discipline underneath my harness setup. The example is hypothetical, but the method is directly testable.
Recovery has tradeoffs
Compaction helps, but summaries can lose important detail
There is no single recovery mechanism. Clear large tool results when they can be fetched again. Compact a long conversation when continuity matters. Keep structured notes outside the active window when decisions must survive several sessions. Start clean when stale instructions dominate. Anthropic's guidance also notes the central risk: compaction may omit subtle details. Test the summary against the source before trusting it.
For high-stakes work, never discard the audit trail merely to make the prompt smaller. Preserve source documents, approvals and test evidence, then load the minimum needed for the next decision. Context management reduces one class of failure; it does not remove the human review and scaffolding tax around shipping reliable systems.
The operating rule
Measure reliable use, not a folklore token number
The useful insight inside “dumb zone” is not that intelligence expires at 100K tokens. It is that accepted context and reliably used context are different quantities. When quality slips, stop treating the conversation as evidence of its own health. Probe recall, compare a focused baseline, preserve the decisions that matter, and verify recovery with tests.
A larger window remains useful. A fresh session is not automatically better. The professional habit is to know what claim you are making, what evidence supports it, and what check would prove the agent wrong. That is good engineering with or without AI, and it leaves more room for work, learning and family than repeatedly repairing a session that has lost the plot.
Sources & caveats. “Dumb zone” is an informal label associated here with Matt Pocock and AI Hero, not a scientific category. The capacity and context-rot claims reflect Anthropic's context-window documentation. Task and position effects are supported by Lost in the Middle and RULER. Recovery tradeoffs follow Anthropic's context-engineering guidance and context-management cookbook. Benchmark results are task- and model-specific; none establishes a universal 100K threshold. Product details are dated 13 July 2026.