Repository navigation
[FEATURE]: V2 background summary preparation with validated context swap #55896
Description
Feature hasn't been suggested before.
- I reviewed related issues and PRs and describe their relationship to this V2 proposal below. The broad feature has been requested before.
Existing requests and V2 scope
This is a V2 design follow-up to marklubin's #15130 and requests #16466 / #27359. Those threads are closed; I am not claiming the broad feature is new. I would like to confirm the current V2 design direction and whether someone is already implementing it.
Describe the enhancement you want to request
On 867a77a38, SessionRunner.runStep awaits automatic compaction before the next normal model request. Input admission during compaction already exists; the proposed change is overlapping summary generation with agent execution.
A limited first version would be opt-in and support local summaries:
- Prepare one summary per session from a frozen, tool-complete history prefix before the existing hard threshold. Keep executing with the original context while it fits.
- At a safe provider-turn boundary, validate the source history and configuration, then commit the summary while preserving the snapshot's recent tail and every message appended afterward, exactly once and in order. This needs a prepare/publish split and an explicit coverage boundary in the durable history projection.
- Invalidate on revert, fork, context/model changes, or cancellation. If no valid result is ready when space is needed, join a compatible job or use the existing bounded foreground path.
I would first validate append/cancel/revert/restart behavior with a gated test provider, then compare blocked time, total latency, extra requests, and tokens under the same workload. No latency or quality improvement has been measured.
Would this scope fit V2, or would you prefer another design or an existing tracking issue? This follows the earlier work rather than claiming a new compaction mechanism.
Activity
opencode-agent commentedon Oct 16, 2026
Thanks for the detailed write-up, @JasperChan929! To restate it: you're proposing an opt-in V2 mode where the auto-compaction summary is prepared in the background from a frozen, tool-complete history prefix. It would then be validated and swapped in at a safe provider-turn boundary, keeping the recent tail and anything appended since, instead of
SessionRunner.runStepwaiting for compaction before the next model request. If no valid summary is ready, it would fall back to the existing foreground path.I checked current
dev, and auto compaction is still awaited inline inpackages/core/src/session/runner/llm.ts. I didn't find an open V2 issue or PR that already tracks this. Related threads, most closely related first:This needs changes inside the session runner and the stored history, so it can't be done as a plugin. Maintainers will consider the proposal and whether this scope fits V2.
JasperChan929 commentedon Oct 17, 2026
Following up on the design question above: I suggest keeping this an opt-in proposal with explicit acceptance gates before considering broader use.
The contribution I want to evaluate is the safe scheduling and validated context swap described in this issue. A production speedup, cost reduction and foreground non-interference still need evidence. Would maintainers prefer this restricted scope, or a smaller prepare/publish primitive first?