Context-compression thresholds are reliability budgets

A context-compression threshold is a reliability budget, not a token-utilization setting. It decides how long an agent may accumulate evidence before some of that evidence is transformed, discarded, or made harder to retrieve. Setting it at “80% of the model window” without naming what must survive is equivalent to setting a database retention policy from disk-full alerts.

Long contexts do not fail only at the advertised limit. Performance can degrade well before it, especially when a trajectory mixes machine-generated actions, verbose observations, tool outputs, corrections, and abandoned branches. The problem is not simply too many tokens. It is that relevant causal state becomes harder to distinguish from plausible but obsolete state. Waiting longer can preserve bytes while reducing usable signal.

I therefore treat the threshold as two coupled budgets. The capacity budget reserves enough room for the next observation, tool result, recovery attempt, and final response. The information-loss budget defines which classes of state may be compressed and what fidelity each requires. Goals, approvals, committed effects, unresolved errors, and provenance need stronger preservation than duplicated tool output or explanatory chatter. One percentage cannot express both decisions.

This extends the argument that context compaction is lossy compression. A loss function says what may disappear; a threshold says when the system is allowed to spend that loss. Active compression research makes timing consequential: compressing after a coherent exploration segment can remove dead ends cleanly, while compressing on a fixed turn count may split the evidence from the action it explains. The sawtooth pattern — expand during exploration, contract after consolidation — is a runtime policy, not a cosmetic prompt trick.

The threshold should respond to trajectory shape. A burst of large tool results can justify clearing raw payloads early after storing their identifiers and extracted claims. A short sequence containing an approval and an external write may deserve no lossy compression until the effect is reconciled. Repeated summaries should trigger their own guard because recursive condensation compounds omissions. Long-horizon agents lose the plot gradually; compression can either arrest that drift or institutionalize it.

Observability needs to make the budget inspectable. For every compaction event I want the pre- and post-token counts, trigger reason, protected fields, artifact identifiers, summary version, and a small preservation evaluation. Tests should ask whether the compressed state still supports recall, causal inference, state updating, and abstraction — the four distinct capabilities surfaced by agent-memory benchmarks. Aggregate answer quality hides which one was spent.

A separate terminal budget matters too. If repeated compression no longer creates enough safe headroom, the runtime should checkpoint, hand off, or stop rather than compress indefinitely. Budget exhaustion is a legitimate terminal state. It is more honest than returning a fluent result from a context that has forgotten the conditions under which the task began.

There is one precise concession: a fixed percentage is a reasonable initial trigger for short, low-risk agents with uniform tool payloads and no durable effects. It is easy to operate and better than waiting for an API rejection. The boundary is risk and horizon — once trajectories vary materially or decisions have consequences, the fixed trigger must yield to protected-state and event-aware policies.

My review question is not “How large is the context window?” It is “At each compression point, what evidence may the system lose, and how will we know it did not lose more?” Context engineering is schema design; the threshold is that schema’s retention and headroom policy made executable. Reliability depends on owning it explicitly.