Context and automatic compaction

There is a limit to how much a model can hold in a single request. Klaus computes it as follows:

• Effective window = model context window − output reserve (the window defaults to 200K tokens, the reserve defaults to 20K, and the reserve never exceeds the model's own single-output limit).
• Compaction threshold = effective window − an absolute reserve of 13K tokens. The reserve is absolute rather than proportional because what has to be freed when it triggers (this turn's reply plus the summarization request itself) is a fixed cost that does not grow with a bigger window; a percentage-based reserve would waste hundreds of thousands of tokens on large windows.
• When the threshold is reached: history is replaced with a summary and the conversation continues.

Of the usage-triggered tiers, only "reached" is on by default, and this one does make you wait — if a long session suddenly stalls at some point and then carries on, that is it. There are three further early actions, none of which has a switch in the UI (only the engine configuration changes them); the first two are off by default and the third is on by default:

• Early light cleanup: once usage reaches "threshold − 15% of the effective window", the bodies of early tool outputs are dropped. Cleanup only counts as sufficient if it brings usage down to "threshold − 5% of the effective window"; otherwise it escalates to a full compaction.
• Background pre-summarization: at "threshold − 7% of the effective window", the summary is computed in the background ahead of time, so reaching the threshold does not have to block.
• Idle micro-cleanup (on by default): when a session has been cold for more than 60 minutes and you send the next message, old tool results are cleared first (the most recent 5 are kept verbatim). The interval threshold is set to the longest prompt-cache lifetime among providers, so this can never cause a cache miss that would not have happened anyway.

The context usage pie next to the input box has three states: normal, approaching the limit at 85% of the threshold, and over the limit once the threshold is reached.

Two circuit breakers

Repeatedly failing compaction and repeatedly wasted compaction are both real failure modes, so beyond the thresholds above there are two protections:

• No-progress breaker: a compaction only counts as a real reduction if it brings usage below 99% of what it was — trimming an already tiny result does not qualify. After three consecutive compactions with no material progress, the breaker trips and no more model calls are burned.
• Fast-refill churn breaker: the other failure mode is a compaction that genuinely succeeds (tokens really were freed, so the breaker above does not trip) while the context climbs back to the threshold within two or three turns — because the same oversized input (a huge file, a huge tool result) keeps being read. A compaction must hold the context below the threshold for three turns to count as healthy; failing to hold it is one fast refill. After three in a row the breaker trips, and the turn stops with a recoverable error instead of burning the whole turn's budget on back-to-back compactions.