When to Clear an Agent's Context: A Measured U-Curve

Every team that runs coding agents sooner or later grows its own rule of session hygiene. Some clear the context after every task: a short prompt is a cheap prompt. Others never clear it: let the model keep what it has learned about the codebase. Both rules are defended with confidence. And neither, as far as I know, has ever been measured.

The question is not academic. In agent work most of the money goes not on what the model writes but on what it re-reads. Session length is the one lever that changes how much context gets re-read. And every operator already has it: it costs nothing and needs no access to the model.

So I measured it.

Twelve independent programming tasks. Each is stated in one sentence and checked by unit tests. The tasks and their order are the same in every run.

The agent is Claude Code in non-interactive mode, one invocation per task. Continuing a session means passing the continue flag; starting a new one means leaving it out. It is exactly the mechanism people use in production, not a simulation.

Six conditions: a fresh session every task, every two, three, four, six, and one session for all twelve. Six replicates each. That is 36 runs and 432 task executions. The model is the same everywhere: the question is about the shape of the curve, not about comparing models.

Cost is modeled from the measured token counters and the published prices, separately for input, output, cache writes and cache reads. Comparisons use exact permutation tests: with six replicates per condition, all 924 splits are enumerated, with no assumptions about the shape of the distribution.

And one detail about quality. If the cheaper policy does less work, comparing cost means nothing. So every run ended with the full test suite, and that was a gate, not a side metric.

Cost is not monotone. When the context is cleared after every task, a run costs 2.68 dollars. Every third task, 2.14. Never cleared, it gets more expensive again: 2.47.

So the most expensive policy is the one many teams choose by default: a fresh session for every task. It costs 25 percent more than the best one. And never clearing costs 16 percent more than the best.

The statistics agree. Clearing every third task is cheaper than clearing after every task with a p of 0.0022, the smallest value this design can produce at all. Every single run at the optimum was cheaper than every single run in the worst condition. It is also cheaper than never clearing, with a p of 0.0108.

But between three, four and six tasks per session the difference is within noise. So the honest reading is this: the optimum is not a point but a plateau. Anything from three to six tasks per session sits on the same flat bottom. And both policies people actually use, one task per session or one session for everything, sit outside it.

Quality was identical everywhere: 4086 tests, zero failures. No condition bought cheapness by doing less work.

Two effects build it, and they pull in opposite directions.

First: the longer the session, the fewer model calls. From ninety-four down to sixty-three. A fresh session has to rediscover what is in the working directory and spends calls on orientation that a long session doesn't need.

Second: the longer the session, the more context per call. From 38 thousand tokens up to 71 thousand. Nothing is dropped inside a session, so the transcript of every earlier task is paid for again on every later call. A token that entered the context on the fifteenth call of a hundred is paid for roughly eighty-five more times.

Cache reads are the product of those two numbers. One falls, the other rises, and their product makes a U.

But clearing is not free either. Every fresh session has to fill the cache again, and a cache write costs twelve and a half times as much as a cache read. When the context is cleared after every task, cache writes alone eat 95 cents of the 2.68 dollars.

That is why this mistake is so hard to notice. A team that clears all the time sees a small context and thinks it is saving money, while it pays in cache writes. A team that never clears sees no re-priming and also thinks it is saving money, while it pays in re-reading. Neither sees the other side of the bill.

Six replicates are enough to separate the ends from the middle, but not to rank the conditions inside the middle. I don't claim that three beats four.

One model and one task suite. Where exactly the minimum lands almost certainly depends on the price ratio between cache writes and cache reads, and on how much orientation the tasks need. I claim the shape of the curve and the mechanism, not that three is a universal constant.

And the tasks in the suite are mostly independent. If each one built on the previous one, long sessions would gain more, and the minimum would move to the right.

Session length is a free lever with a 25 percent spread. And the best setting is neither of the two that people use. Clear the context, but not after every task.

More useful than any single number is the reason for the shape. Clearing trades cache writes against re-read context, the two move in opposite directions, and the ratio of their prices decides where the balance falls. Any team can find its own minimum in a day.

To see this in your own sessions, I released an open tool called contextburn. It reads the transcripts Claude Code already writes on your machine and shows what share of the tokens you paid for became work and what share was re-reading. The raw data for all 36 runs is open on Hugging Face, Kaggle and OSF, and the report is on Zenodo with a DOI. The links are at arsentev.ai/research.