Why does recursive summarization at fixed intervals beat ad hoc 'when context fills' summarization?

There are two natural ways to decide when to refresh a conversation summary. Policy (a) waits until the live context approaches its token budget, then runs the summarizer. Policy (b) runs the summarizer every N turns regardless. Policy (a) looks more efficient because it only summarizes when forced to. In practice, three things go wrong with it. First, the trigger fires irregularly. One session crosses the threshold at turn 18, another at turn 42, depending on how chatty the user is. The summarizer sees wildly different input sizes each time, and summary quality varies because compressing 18 turns into 500 tokens is a different job than compressing 42 turns into 500 tokens. Second, the latency hits a single unlucky turn. Most turns are fast, but the one where the trigger fires takes seconds longer because the summarizer runs synchronously. Users notice the spike. Third, evaluation gets harder. The summarizer's input distribution shifts with session length, so you cannot measure quality consistently across sessions. Policy (b) fixes all three. Every N turns, a roughly equal amount of content gets summarized. Cost is spread evenly across turns. The summarizer's input distribution stays stable, so you can evaluate it. Production teams overwhelmingly pick (b) once they have run (a) in front of real users.

**Recursive summarization at fixed intervals** beats the at-threshold policy in production because the at-threshold policy concentrates costs and variance onto specific turns and specific sessions, while a fixed-interval policy spreads them evenly. The at-threshold policy fires when the live context approaches its budget. The trigger is irregular by session because users have different conversation densities. The summarizer's input size varies widely: one session triggers at 18 turns, another at 42, and the same prompt has to handle both. Summary quality degrades nonlinearly with input size, so the cross-session quality variance is high. Worse, the latency cost lands on one turn: most turns are sub-second, the trigger turn is multi-second, and users notice the spike. The naive efficiency argument (fewer summarizer calls per session) does not survive contact with that user experience. A fixed-interval policy fires every N turns. Each invocation sees roughly the same amount of content, so the summarizer has a stationary input distribution. That stationarity is what makes the policy easier to evaluate: you can measure summary quality on representative inputs and trust the measurement to generalize. It is also what makes summary quality consistent across sessions, because the model is always doing the same-sized job. The cost is spread evenly across turns. There is no spike. Production teams running both policies in A/B find that perceived chat quality improves under the fixed-interval policy because the user never hits a multi-second pause. The compounding wins are concrete: predictable latency, stable eval surface, consistent fidelity, simpler capacity planning. The at-threshold policy is an attractive abstraction that loses in every concrete dimension that matters in production.