Context Is a Budget
Everything Claude Code (ECC) treats context as a finite operating budget: the specific problem is deciding what an agent should read, which work should be delegated, and which checks should happen outside the model's conversation. This matters because both extremes are expensive. Sending an entire repository buries the relevant evidence, while sending almost nothing leaves a worker guessing about names, interfaces, and local conventions. The practical outcome is a bounded retrieval and delegation loop, paired with deliberate choices about models, compaction, and tool connectors.
Context is more than the words in a prompt. It includes instructions, skill descriptions, tool schemas, files returned by searches, prior attempts, test output, and the model's own working assumptions. Each addition can help, but each also competes with the information needed for the next decision. ECC's answer is not to minimize context at all costs. It is to spend context where it changes the quality of the decision and keep other work in artifacts, hooks, or scoped workers.
Why both extremes fail
Suppose an agent must change an authentication flow. If the orchestrator sends the whole repository to a worker, the worker receives routes, unrelated UI, generated assets, historical migrations, and several possible conventions. The relevant files are present, but relevance is not the same as attention. The worker may spend its context discovering the shape of the repository instead of checking the token boundary that matters. Large inputs also make it harder for the orchestrator to tell which facts actually support the worker's conclusion.
The opposite strategy is to send only a short instruction: “Fix the authentication expiry bug in the session code.” That saves space but hides the project's vocabulary and dependencies. The worker may not know whether “session” means a database record, a cookie, a refresh-token helper, or a test fixture. It may miss an importer, assume a date format, or edit the obvious file without seeing the caller that constrains its behavior. A small request is not automatically a focused request; it can simply be an under-specified one.
ECC's iterative-retrieval pattern starts between these extremes. A dispatcher makes an initially broad query for candidate files and terms. The returned material is evaluated for relevance and for missing context. The next query uses the vocabulary discovered in the first pass, adds likely call sites or related concepts, and excludes confidently irrelevant material. The loop stops when the high-relevance evidence is sufficient and critical gaps are closed, or after a bounded number of cycles. The documented pattern allows at most three cycles. That limit prevents “retrieve until the model feels comfortable” from becoming an unbounded context drain.
The important unit in this loop is not a file count. It is a justified relationship. For an expiry bug, a session manager may be directly relevant; a token utility may explain the timestamp calculation; a route or test may establish the public behavior. A user-profile component that merely mentions login could be related in vocabulary but irrelevant to the failure. ECC's pattern asks the worker or orchestrator to say why each returned item matters and what remains unknown.
The same issue appears when an agent delegates to another agent. A worker can summarize twenty files and protect the main conversation from their full contents, but it does not automatically know the purpose behind the request. The orchestrator may be trying to decide whether a migration is safe, while the worker interprets the task as finding a symbol definition. ECC's guidance therefore treats the worker's answer as an intermediate result: evaluate it, ask a targeted follow-up when a gap matters, and only then accept the summary as context for the next phase.
This is why “use a subagent” is not a complete context strategy. Delegation changes where reading happens. Iterative retrieval changes how the system discovers what reading is needed. The combination is useful when the main process supplies objective context, the worker has a clear scope, and the handoff preserves evidence rather than a vague conclusion.
Consider how the three-cycle limit behaves in practice. The first pass might find the session implementation and a handful of tests, but reveal that the repository calls the relevant operation “refresh” rather than “expiry.” The second pass can search that local vocabulary and locate the token helper and its callers. The evaluation step may then show that the failure depends on a date format or a migration contract not yet inspected. A third pass targets that gap. If the evidence is now sufficient, the worker returns a small, reasoned set. If the date contract is still missing, the correct output is a declared uncertainty or a request for more authority, not a confident patch built on the most convenient assumption. The loop has a termination condition precisely so a model cannot treat more reading as a substitute for a decision about sufficiency.
That discipline also prevents a subtle delegation failure: a summary that is concise but untraceable. “The session logic is safe” saves many tokens and communicates almost nothing. “The refresh path reads the expiry value, the caller retries only after a particular error, and the existing test covers the boundary but not a stale token” gives the next agent a smaller context with more usable structure. Context optimization is therefore about evidence density, not compression alone.
The retrieval diagram has an important failure path: the system may reach its cycle limit with gaps still open. The limit is an efficiency and safety constraint, not a guarantee of completeness. If an exact claim remains unsupported, the responsible response is to mark the uncertainty or change the task's scope, not to fill the gap with a plausible guess. A bounded process is useful only when it can stop without pretending that stopping proves enough.
Spend context where it changes the outcome
Once the evidence set is bounded, ECC makes a second allocation decision: which kind of reasoning should handle it? Its guidance recommends the least expensive model that is sufficient for the task. Haiku is described as suitable for exploration and simple lookups, Sonnet for ordinary coding and review, and Opus for difficult architecture, subtle debugging, or security analysis. These are routing recommendations, not an independently reproduced performance table. The underlying principle is stronger than any particular model label: do not pay for the deepest reasoning when the task is deterministic, and do not use a lightweight worker for a decision whose failure is costly or architecturally subtle.
Model routing is not a shortcut around context design. A stronger model receiving an undifferentiated repository can still spend its attention on the wrong evidence. A cheaper model with a narrow question, relevant excerpts, and an explicit stopping condition may be entirely adequate for exploration. Conversely, a security decision with a deceptively small diff may deserve deeper reasoning because the risk is in the boundary, not in the number of changed lines. ECC's model guidance works best when the task's scope, failure cost, and evidence requirements are decided before the model label is chosen.
The division of labor follows from the context problem. An exploration worker can locate likely files and return a concise map. A planner can compare dependencies and risks. An implementation agent can use the approved plan and focused evidence. A reviewer can inspect the diff without inheriting every assumption that led to it. A security reviewer may need a broader threat model than a formatter or test runner. Model routing works when the role and evidence are bounded; simply assigning a cheaper model to an unbounded task turns a cost decision into a quality gamble.
The same logic applies to compaction. A long session accumulates stale exploration, failed approaches, test output, and partial implementation details. Clearing or compacting at a logical boundary can remove material that no longer helps the next phase, especially after research is complete or a milestone has been verified. But compaction during an active multi-file refactor can remove the variable names, partial state, and failure details needed to continue safely. ECC's strategic-compaction guidance therefore treats timing as part of the workflow. The right question is not “can the context be smaller?” but “has the current state been externalized well enough that this context can be discarded?”
An active implementation usually contains at least three kinds of state: the intended change, the current code state, and the unresolved failure state. A plan can preserve the first. A diff and tests can expose much of the second. The third often lives in the exact error message, the attempted hypotheses, and the experiment that ruled one out. Compacting after those facts are captured in a handoff or test report can be safe. Compacting while a failure is being diagnosed can force the next session to repeat the same exploration, increasing both cost and the chance of a different guess.
This is where plans, tests, and handoffs become context infrastructure. A plan can replace a long exploratory conversation with a checked list of intended changes. A test report can replace a transcript of repeated runs. A handoff can record what worked, what failed, what remains unknown, and what action comes next. Without those artifacts, compaction saves tokens by deleting the very state that makes resumption reliable.
Hooks can help because selected checks run outside the model's conversational context. A formatter, type check, or session-state writer does not need to be narrated in full every time for the model to remember that it happened. The result can return as a compact signal. This does not mean that all hook output is free: large outputs can still consume context, and a failed hook may require diagnosis. It means the system can move routine enforcement to a boundary designed for it rather than asking prose to carry a recurring obligation.
Tool connectors create a similar trade-off. An MCP server can be valuable when the task needs an interactive, stateful session—for example, a live browser debugging connection that maintains a protocol state across calls. But a connector also contributes tool schemas to the environment. ECC's connector policy therefore asks two questions before making a server a default: is the job universal across the supported harnesses, and does MCP provide something a CLI or REST-wrapping skill cannot? Stateless GitHub or documentation requests can often be handled by a skill that invokes an established CLI or API when needed, rather than loading a large set of tools into every session.
This policy is not an argument that MCP is bad. It is an argument for matching the mechanism to the job. A stateful browser inspection session has a different value from a one-shot issue lookup. An opt-in connector can remain available for users who need it without imposing its schema and credentials on users who do not. ECC's current default connector choice is a design decision that may change as harnesses gain native capabilities; its general lesson is to price tool descriptions and permissions as part of context, not as invisible infrastructure.
The result is a layered budget. Load a skill when the task needs its reasoning. Keep standing rules narrow. Delegate exploration when a bounded summary protects the main context. Use a more capable model when the decision demands it, not by reflex. Compact after state has been made durable. Prefer a connector when its statefulness or interaction is material, and a CLI/API skill when the work is stateless. At every point, ask what evidence will be lost if the context is reduced and where that evidence can be preserved instead.
That last question leads directly to quality. A focused context is not valuable because it is small; it is valuable when it contains the facts needed for the next decision and leaves a trace that another process can inspect. ECC's context strategy is therefore an input to its engineering loop, not a separate cost-optimization hobby. The next test is whether a bounded context can produce a bounded, reviewable change.