A session can last longer than the context window of any one model request. The application can keep saving events while the harness selects a smaller input for the next call.
That leaves a difficult question: what must survive the reduction?
A summary can keep the broad decision and lose the exception that made it safe. Recent turns can preserve a tool result while omitting why the tool was called. A readable handoff is useful, but it is not a correctness proof.
First distinguish the records
The saved history records what happened. The next model input is a constructed view. A compaction checkpoint is one way to represent enough earlier material to continue with a bounded input.
None of these is the inference service’s KV cache. Replacing history in the active input changes the token prefix and can invalidate reusable state even when the original events remain intact.
What did the shorter input retain?
| Saved fact | Included in next input? |
|---|---|
| Use staging | no |
| Never send external requests | no |
| Last tool failed | yes |
The three policies use preset synthetic text and a fact-inclusion check. The control is not calling an LLM or measuring summary quality. It makes one failure visible: an omitted restriction cannot be assumed from the shorter view.
What does the 255k number mean?
A displayed budget can come from the model’s documented window, separate input/output limits, a reserved response allowance, a client compaction trigger or an approximate token counter. Those numbers need not be equal.
I have not established an authoritative universal 255,000-token OpenAI limit or an internal reason for choosing it. An exact claim needs its model/API and client revision. A nearby threshold is not evidence of a general quality cliff.
The earlier source review pinned Codex’s model/context configuration rather than treating one UI number as a model property. The relevant fact is the policy being executed in that installation.
How do public harnesses approach it?
In the reviewed Codex revision, remote compaction produces a checkpoint used with retained items under a bounded policy. A text-summary fallback has a different representation. Resume reconstructs the selected view from persisted state. These mechanisms establish how context is rebuilt; they do not guarantee that every earlier constraint appears in it. Codex remote compaction
The reviewed OpenCode revision combines summary handling with a recent-context allowance. Its recent-text rendering can omit reasoning and turn attachments or long tool payloads into descriptions/previews. “Keeps recent messages” therefore needs an explanation of the retained format. OpenCode compaction, recent-text rendering
Pi’s public engineering account describes summarizing older material while retaining recent messages and saving a compaction entry. It also explains the resulting prefix-cache change. Its configurable budget and triggering policy should be checked against the installed revision.
These are dated public mechanisms, not a ranking of which summary is most faithful. I am not reproducing private Pal compaction logic here.
What would I preserve exactly?
Some material deserves stronger handling than a prose paraphrase: active permissions, output schemas, unresolved tool calls, references to artifacts, and explicit exceptions to earlier decisions. Provenance matters too. A failed tool result should not become a confident statement that a change succeeded.
A useful checkpoint should say what is done, what is pending, what evidence supports it and where the original detail can be recovered. Retrieval from the durable record can complement a compact working context, provided the harness can identify the relevant records and reintroduce them with their meaning intact.
Keeping everything is not free, but compressing everything into one unstructured paragraph is also a policy choice with costs.
How would the personal experiment work?
The current lab selects whole completed turns and saves the exact model request. It does not yet implement semantic summarization. Its offline codeword experiment establishes that omitted history can remain recoverable from the record; it is not a model-memory accuracy result.
I would compare recent-turn selection with one summary-plus-recent policy under the same active-input budget. Use synthetic sessions containing an initial rule, a later exception, a correction, a tool failure and a task requiring several pieces together. Keep the full record as the recovery source.
Offline checks can test event provenance, tool-call/result pairing and selection. Real model trials are required to evaluate whether the next task obeys constraints. Record violations and completed tasks alongside compaction calls, cache behavior and all charges.
A good memory policy is one we can explain and test: what was retained, what was omitted and how the agent recovers the evidence it still needs.