Context engineering beats a bigger context window

Claude Code now runs up to a 1M-token context window on flagship models - but a bigger window does not fix a cluttered one. Every turn resends the entire conversation, and answer quality degrades before the hard limit is ever reached. The lever that matters is context engineering, not window size.

Definition

Context window - the maximum number of tokens a model can consider at once, covering the system prompt, the full conversation history, tool results, and the model’s own replies.

Context engineering - deliberately curating what enters that window each turn, instead of trusting a larger window to absorb the clutter.

The window got bigger; the failure mode didn’t

Anthropic’s current paid-plan limits (verified against Anthropic support, June 2026):

On Pro, unlocking the 1M window for Opus and Sonnet 4.6 in Claude Code requires enabling usage-based credits; Enterprise plans that already bill on usage skip this step.

A 1M window sounds like it ends the problem. It doesn’t, for two reasons.

Cause: every turn replays, and the middle gets lost

Replay. An agent turn is not just your latest prompt. The model re-reads the entire state every time: prior messages, its own previous responses, tool outputs, file reads, and any docs it fetched. A single large file read or doc fetch keeps costing tokens for the rest of the session.

Lost in the middle. Recall is strongest at the very start and very end of the window and weakest in between. Liu et al. measured the shape directly in Lost in the Middle: How Language Models Use Long Contexts (TACL 2024): holding the input identical and moving only the position of the relevant document, accuracy traces a U - highest when the answer sits at the beginning or end, lowest when it sits in the middle. The finding held on both multi-document QA and a synthetic key-value retrieval task, so it is a property of how the window is read, not of one benchmark’s subject matter.

The consequence for an agent session is the part that gets missed: a fact buried mid-context can be ignored while the token count is still far under the cap. Quality drops before the hard limit, not at it - which is why “we have not hit the ceiling yet” is not evidence that the window is healthy. See lost in the middle.

The result: throughput and accuracy fall as the window fills with low-signal content, regardless of how high the ceiling is.

Solution: engineer the context

Symptom - the agent forgets earlier instructions, repeats work, or references files it was never shown. Cause - a bloated, low-density window. Solution - four moves:

• Keep CLAUDE.md lean. It loads at session start and costs tokens every turn. Put only universally applicable facts in it; pass task-specific detail in the prompt. See keep CLAUDE.md to universal instructions.
• /compact proactively. Summarize the conversation before it sprawls, and append an instruction telling it what to preserve (for example, the auth flow you’re mid-change on).
• /clear between tasks. When you switch to unrelated work, reset to zero tokens instead of dragging the old context along.
• Plan outside, paste the result in. Do exploratory back-and-forth somewhere cheap, then inject only the final plan - not the dead ends that produced it.

The two reset commands, in their official form:

/compact focus on the auth flow I'm mid-change on
/clear   # reset to zero tokens between unrelated tasks

Push heavy reads into a subagent

The highest-leverage move for large reads is delegation. A subagent runs in its own context window and returns only a summary to the main agent. Reading an MCP (Model Context Protocol) server’s API reference or a pile of source files can cost tens of thousands of tokens - in one demo run, an API planner reading Stripe’s docs through Context7, an MCP server that exposes live docs as a tool call, consumed ~54K (illustrative of the scale, not a benchmark). Done in the main window, that clutter persists for the rest of the session; done in a subagent, the parent receives just the conclusion.

Reach for it when a task needs a large doc or many files read but the main loop only needs the answer. A subagent is also where you drop to a cheaper, faster tier - Haiku 4.5 reads the pile while Opus or Sonnet keeps the plan - so the context isolation and the token savings compound. See subagent context isolation and pick the right Claude tier.

Bottom line

The window will keep growing. The discipline that makes agents reliable - context engineering - does not change with it. Treat the window as a budget to spend deliberately, not a bucket to fill. That token budget maps onto a real cost line: Google’s 2026 SDLC whitepaper treats context and model routing as financial levers - the case made in vibe coding vs agentic engineering: same agent, different harness. JetBrains Research found the same discipline holds model-agnostically, on a coding-agent benchmark, with a concrete price tag attached - see prune the log, not the window.

The lean baseline is installable: npx leanharness drops a ten-file starter into any repo - a 60-line CLAUDE.md, read-only subagents for the heavy reads and the fresh-context review, and a verify-before-done loop.

None of this needs an agent to matter. The same budget logic decides whether a paste into a chat window gets used or ignored, which is where how to use ChatGPT effectively picks it up for readers who never touch an API.