Field note from a few weeks of running agent-mode on a large-ish repo: the thing that quietly wrecks a long session isn’t a bad edit, it’s context bloat you can’t see. The agent keeps pulling more files in, the token count creeps up, and by the time it feels sluggish or starts dropping earlier instructions you’ve already burned the budget.

What actually helped me was making the cost visible before the run instead of after. Two cheap habits:

  1. Budget the prompt, not just the diff. Before kicking off a background agent on a task, I do a rough token count of what it’s likely to load (the files I @-mention + their obvious imports). If the “starting context” is already a big fraction of the window, the run is going to degrade — so I split the task instead of hoping.

  2. Attribute tokens to files. When a session gets expensive, the culprit is almost always one or two fat files (a generated client, a giant JSON fixture, a barrel index that drags in everything). Counting tokens per included file — not per message — points straight at them. Usually the fix is “don’t feed the agent the generated file, feed it the schema.”

The mental model that stuck: treat the context window like a CI cost gate. You wouldn’t merge a PR that 10x’d your build time without noticing; same idea for the tokens an agent pulls per task. A number you can see at the start changes the plan; a number you discover at the end just explains the failure.

Curious how others here keep long agent runs from silently outgrowing the window — do you prune context manually, split tasks, or just restart the session when it gets heavy?