Clear Every Third Task: A Measured U-Curve in the Context Economy of Coding Agents

Corrected 2026-09-15 (version 1.2): versions 1.0 and 1.1 priced the token counters incorrectly. The costs, percentages and p-values below are recomputed at the correct prices; what changed is listed at the end of this abstract.

Practitioners running LLM coding agents face a question with no published answer: how often should an agent's context be cleared? We ran a fixed suite of twelve programming tasks under six session-length policies — a fresh session every task, every two, three, four, six, and one session for all twelve — with six replicates each, holding the model, the tasks and their order constant. Cost is not monotone in session length. It falls from $2.17 per run when the context is cleared after every task to $1.62 at every third task, then rises to $1.78 when the context is never cleared.

Exact permutation tests show that clearing every third task is significantly cheaper than clearing after every task (+33.5%, p = 0.0022, the smallest value this design can produce; 0.011 after Holm adjustment over five comparisons) and than clearing every second task (+14.3%, same p). Never clearing is 9.7% more expensive in the point estimate, but not significantly so (p = 0.046 unadjusted, 0.14 adjusted). The differences between clearing every three, four and six tasks are within noise (p = 0.17 and p = 0.45). The low region is a plateau rather than a point. Clearing after every task sits clearly outside it; whether never clearing does too is not established at this sample size. No run produced a test failure: across all 36 runs, 4086 tests executed and 4086 passed. That figure is a total over the experiment, not a per-condition value. Per condition the counts are 701, 697, 687, 699, 661 and 641, and per run they range from 97 to 127. The suite is written by the agent as part of each task, so this gate cannot establish that the conditions did equal work.

The U-shape decomposes cleanly. Cache writes fall monotonically with longer sessions (253k → 88k tokens), because each fresh session re-primes the cache. Context carried per model call rises monotonically (38k → 71k tokens), because nothing is ever dropped. Their product, cache reads, is U-shaped with a minimum at three. On the model we used, a 1-hour cache write costs 20× a cache read per token, so neither term can be ignored. We release the run-level token counters and the harness.

What the 2026-09-15 correction changed. Versions 1.0 and 1.1 used $3.00/$15.00 per million input/output tokens, priced every cache write at the 5-minute rate ($3.75) and cache reads at $0.30. claude-sonnet-5 is listed at $2.00/$10.00, and every cache write in these runs is a 1-hour write ($4.00; reads $0.20). The earlier versions reported that clearing after every task costs 25.3% more than clearing every third task (now 33.5%), and that never clearing costs 15.6% more with p = 0.0108 (now 9.7%, p = 0.046, not significant after adjustment). The claim that both extremes are significantly worse is therefore withdrawn for never clearing. The price ratio between cache writes and reads was given as 12.5× (now 20×), and the spend split at the optimum as 44/23/33% for read/write/output (now 39/32/29%). The minimum stays at three tasks per session. The recomputation scripts are published with version 1.2 (DOI 10.5281/zenodo.22759217).

Version 1.1 (14 September 2026) corrected two statements in the version 1.0 abstract: that the design held the verification suite constant, and that 4086 tests were run in every condition. It also added the per-condition test counts, the model snapshot (claude-sonnet-5, Claude Code 2.1.252, Node v24.20.0), an explicit note that temperature was never set and is not recorded, and a threat to validity recording that the verification suite is agent-authored. Earlier versions remain citable at DOI 10.5281/zenodo.22699668 (1.0) and 10.5281/zenodo.22749959 (1.1).