When Sourcegraph benchmarked coding agents on identical tasks, agents handed a 100K-token codebase summary performed worse than agents handed 5K tokens of targeted retrieval. Twenty times the context, and the results got worse - not noise-level worse, measurably worse. That is the headline finding of 2026's coding-agent research, and the industry has not fully absorbed it yet.
The instinct that more context means a better-briefed, better-reasoning agent is now the closest thing this field has to a founding myth. The data says it should be retired.
Why long context windows stop helping coding agents
The window tells you what fits. It does not tell you what the model attends to. A 1M-window model can start degrading meaningfully at 50K tokens. The window tells you what fits; it does not tell you what the model attends to. The practical rule: effective capacity is roughly 60-70% of the advertised maximum, and the drop-off is rarely gradual. Models typically hold performance until hitting a threshold, then fall sharply.
Context rot and long-context degradation are well documented: LLMs systematically miss information placed in the middle of a long input, producing a U-shaped accuracy curve across question-answering and key-value retrieval tasks. That result from 2024 has not been fixed by larger windows. Recall on facts buried mid-prompt still drops 25-40% on 1M+ token windows; frontier 2026 models narrowed the gap but did not close it.
The economic case is equally stark. In 2026, agents routinely send 50,000-500,000 input tokens per request against only a few hundred output tokens. Production agents are not compute-bound on generation - they are compute-bound on context. A ReAct agent making 10 tool calls in a session might produce 500 output tokens total and consume 800,000 input tokens, because each call carries the full system prompt, tool schemas, and conversation history.
In Claude Code specifically, every new message re-sends the entire conversation history as input tokens. That 200-message session you've been running for two hours? Message 201 costs as much in input tokens as messages 1 through 200 combined. This is why your credits seem fine for the first hour and then evaporate in the last fifteen minutes.
The Security-Recall Divergence: a second-order cost nobody talks about
There is a subtler failure mode that sits beneath accuracy degradation, and it matters more for agents running in production than any benchmark.
In a 4,416-trial causal study across 12 models and 8 providers at six conversation depths, omission compliance falls from 73% at turn 5 to 33% at turn 16 while commission compliance holds at 100%. The researchers - led by Yeran Gamage, an AI safety researcher at Georgia Tech - call this asymmetry Security-Recall Divergence.
The mechanism is attention dilution. This decay happens because following a prohibition leaves no trace in the conversation history to reinforce the rule, making long-running agents structurally prone to leaking data or executing unsafe code even without an active adversary.
The implication for coding agents is direct: "do not commit to main", "do not call the production endpoint", "do not include secrets in output" - these are omission constraints. Your agent likely obeyed them at turn 3. If your agent violates a constraint it followed correctly 10 turns ago, the model did not change. The attention weight on that constraint dropped below the threshold required to enforce it. That is a memory architecture problem, not a model problem.
Most LLM safety benchmarks evaluate a model's behavior at Turn 1 - the very beginning of an interaction. The industry has largely operated on the assumption that if a model obeys a safety constraint at the start, it will continue to do so throughout the session. It will not, past a certain depth, and the fix is architectural rather than model-level. Re-injecting constraints before the per-model Safe Turn Depth restores compliance without retraining.
Beagle in action#engineering, a long Claude Code session mid-refactorWhat context engineering actually means in practice
Context engineering is not a synonym for prompt engineering. Context engineering is the practice of deciding what goes into the context window, in what order, and how to cache and compress it to minimize prefill compute without hurting output quality. It is distinct from prompt engineering, which focuses on what instructions and examples produce the best outputs. Prompt engineering optimizes quality; context engineering manages resources.
The operative principle: subtract before you add. Counterintuitively, simply enlarging the context window makes things worse. Compressing history into actionable workflow summaries consistently outperformed raw retention.
For teams using Claude Code specifically, storing project context once in CLAUDE.md eliminates 500-2,000 tokens of repeated setup per session, every session. Targeted file inclusion cuts waste: including only files relevant to the task uses 60-80% fewer tokens than loading entire directories, with equal output quality.
Compaction discipline matters too, but timing is the thing most teams get wrong.
The /compact command summarizes the conversation and replaces the raw history with that summary. The earlier you trigger it, the better the summary, because Claude has more headroom to retain what matters and drop what doesn't. A reasonable trigger threshold is ~60% context utilization, not 90%.
The research backs this up at model scale. Four papers from early 2026 cover this problem: the MIA framework showed that a 7B model using structured memory outperformed a 32B baseline by 18%, with gains holding on frontier models. The bigger model, stuffed with raw context, lost to the smaller model with disciplined memory architecture.
Hybrid graph + vector retrieval at 32-128K tokens is quietly beating brute-force million-token prompts on real multi-file edits.
The steelman for long context
There is a real case for wide windows: whole-repository reasoning on a first pass, initial onboarding to an unfamiliar codebase, cross-document synthesis where you genuinely need everything in view simultaneously. A 100K-line repository fills a 1M window before you add the system prompt, conversation history, or tool outputs. In practice, anything above roughly half the window forces a choice - retrieve only the relevant slice via agentic search, or compress the history you carry forward. The wide window earns its cost on that initial read. It does not earn it by staying full for the rest of the session.
The correct pattern is: use the large window for exploration, then compact aggressively before the real work starts.
In 2026, context management, permissions, sandboxes, audit logs, and cost controls matter as much as model quality when choosing and operating an agentic coding tool. The engineering work has moved from "which model is best?" to "how disciplined is my context hygiene?"
That is the actual skill gap on most teams right now. Not prompt wording. Not model selection. The context budget.
Context engineering for coding agents: common questions
What is context engineering for coding agents?
Context engineering is the practice of deciding precisely what enters an agent's context window - which files, which history, in what order - and when to compress or discard it. Unlike prompt engineering, which optimizes instruction quality, context engineering manages a computational resource. The goal is the smallest context that produces the correct output, not the largest one you can fit.
Does a bigger context window mean better coding agent performance?
No. Effective capacity is roughly 60-70% of the advertised maximum, and the drop-off is rarely gradual. Research in 2026 consistently shows that targeted retrieval of the relevant 5K tokens outperforms loading a 100K-token codebase summary. A wider window gives you more room to manage; it does not automatically make management unnecessary.
Why do coding agents forget constraints mid-session?
Prohibition-type constraints decay under context pressure while requirement-type constraints persist - researchers call this asymmetry Security-Recall Divergence. The mechanism is attention dilution: accumulated tokens push the constraint document out of effective attention range. The practical fix is to re-inject critical constraints before the model's per-model Safe Turn Depth threshold, not to hope the model retains them through a long session.
How do I reduce token costs in Claude Code sessions?
Three high-impact moves: store project conventions in CLAUDE.md rather than repeating them each session (saves 500-2,000 tokens per session),
include only files relevant to the task - this uses 60-80% fewer tokens than loading entire directories, with equal output quality
, and trigger /compact at 60% context utilization rather than waiting for autocompact to fire at the end.
Is context engineering worth doing if I'm on a flat-rate subscription plan?
Yes. The token budget on Max and Pro plans is shared across everything you do in Claude. Burning it on stale tool-call traces and repeated setup means fewer productive sessions per day. The accuracy and constraint-compliance arguments also apply regardless of billing model: a session that is 70% full of already-processed context produces measurably worse output than a clean 200K window, at any price point.