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

There are two 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 it every N turns regardless. Policy (a) looks more efficient because it only summarizes when forced to. In practice, three things go wrong. First, the trigger fires irregularly. One session crosses the threshold at turn 18, another at turn 42, depending on how chatty the user is. Summary quality varies because compressing 18 turns into 500 tokens is a different job than compressing 42 turns into the same space. 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 quality is hard to measure consistently. Policy (b) fixes all three. Every N turns, a similar amount of content gets summarized, so each summary job is small. Because the schedule is known, the summarizer can run in the background, and users do not wait on it. The summarizer's input distribution stays stable, so you can evaluate it.

**Recursive summarization at fixed intervals** beats the at-threshold policy in production because the at-threshold policy concentrates cost and variance onto specific turns and specific sessions. The at-threshold policy fires when the live context approaches its budget. The trigger is irregular because users have different conversation densities. One session triggers at 18 turns, another at 42, and the same prompt has to handle both. Summary quality drops as more content is compressed at once, so quality varies across sessions. The latency also lands on one turn: most turns are fast, the trigger turn takes seconds longer, and users notice the spike. The efficiency argument (fewer summarizer calls per session) does not survive that user experience. A fixed-interval policy fires every N turns. Each call sees a similar number of turns, so the summarizer has a stationary input distribution. That stationarity makes the policy easier to evaluate: you can measure summary quality on representative inputs and trust the measurement to generalize. It also keeps quality consistent across sessions. Each call compresses a bounded input (the old summary plus N turns), so it is short and predictable. A synchronous summarizer still pauses on every Nth turn. The known schedule is what lets you run it in the background after turn N, so users never wait on it. The wins compound: predictable latency, a stable eval surface, consistent fidelity, and simpler capacity planning. Keep a hard threshold as an overflow backstop for unusually verbose sessions.