Stop burning tokens on infinite context. Learn patterns for automating context management, iteration limits, and
Why Infinite Context Burns Budget Without Buying Progress
Long-running agent sessions fail less often from model quality than from context that never stops growing. Every tool result, failed attempt, and intermediate draft stays in the window until the model is forced to re-read material that no longer affects the next decision. That cost compounds: later steps pay for earlier noise, latency rises, and the agent starts optimizing for whatever happens to sit near the end of the transcript instead of the goal.
Automating context is not about shrinking history for its own sake. It is about deciding, on a schedule the agent cannot skip, what must remain live, what can be summarized, and what should leave the window entirely. Treat context as a working set with an eviction policy, not as an append-only log.
Separate Working Memory From Durable State
Split what the agent needs right now from what it may need later. Working memory is the active plan, the current file or API surface under edit, open failures, and the acceptance criteria for this step. Durable state lives outside the prompt: notes files, task checklists, commit messages, test output archives, and short handoffs written after each completed unit of work. When a phase ends, write a compact status artifact and drop the raw intermediate chatter that produced it.
Summaries should be lossy on purpose. Keep decisions, constraints, and residual risks. Drop exploratory dead ends unless they still block the path forward. If the agent must re-open a prior step, load the artifact for that step instead of replaying the entire session. That pattern keeps the model focused and makes recovery after a crash or restart mechanical rather than conversational.
Cap Iteration Before Cap Context
Unbounded retry loops are a common way context explodes. Without hard limits, the agent can re-diagnose the same error, re-run the same failing command, and stack near-duplicate tool traces until the window is full of one stuck problem. Put iteration budgets on loops that tend to thrash: compile-fix-fix cycles, search-and-patch attempts, and “try another approach” branches.
- Set a maximum attempts count per subtask, then force a stop, summarize what failed, and escalate or replan.
- After each attempt, retain only the last failure signature and the change that produced it; discard earlier identical stack traces.
- Require a fresh hypothesis when the same error repeats, so the agent does not burn tokens restating the same diagnosis.
Iteration limits turn failure into a bounded experiment. They also create natural checkpoints where context can be compacted without guessing whether the work is “done enough.”
Automate Compaction With Explicit Triggers
Do not wait for the model to notice the window is full. Trigger compaction on events you can measure: after a successful test suite, after a file is committed, after N tool calls, or when estimated token use crosses a threshold you define for the session type. At each trigger, rebuild a short system-facing brief: goal, completed steps, open tasks, invariants, and the single next action. Reinject only the files or snippets required for that next action.
For multi-hour or multi-day work, prefer session handoffs over continuous transcripts. End a session with a structured brief another agent can load cold. Start the next session from that brief plus current repo state, not from a megabyte of prior chat. The payoff is practical: lower token spend, cleaner reasoning, and agent runs that stay useful long after the first context window would have turned into noise.