[FEATURE]: Compaction hook can only return a summary string, so a plugin cannot replace the window with messages #50862

Activity

1. github-actions

   assigned

   jlongster

   on Sep 23, 2026
2. github-actions commented on Sep 23, 2026

   

   github-actionsBot

   on Sep 23, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: V2 plugin support for managing context-window transitions #47810: Requests V2 plugin support for managing context-window transitions, including taking over compaction without a generated summary — closely aligned with this request to allow plugins to supply a replacement message window from the compaction hook.
3. jutaz commented on Sep 23, 2026

   

   jutaz

   on Sep 23, 2026

   Author

   More actions

   Checked #47810. It's close, and I'd missed it — but I think it's the other half of the same wall rather than the same ask.

   #47810 is about the trigger: builtin compaction runs before the request hook or during overflow recovery, so a plugin can't own the transition. required() reads durable history, which is why pruning in ctx.session.hook("context") doesn't stop it.

   This one is about the return value: when the hook does fire, SessionCompactionResult (packages/plugin/src/promise/session.ts:38) only carries summary: string, so a plugin that knows which messages to keep has to render them into prose.

   They bite together. Suppressing automatic compaction still leaves you writing a summary; returning messages still leaves the host compacting on its own schedule. I described #47810's problem in the body here without realising it had an issue.

   Happy to have these consolidated — #47810 is older and the broader framing, so if one should carry both, it's that one. I'd just want the summary-only return type named explicitly in whichever survives, since it's the part no existing issue states.
4. everest-an commented on Oct 3, 2026

   

   everest-an

   on Oct 3, 2026

   More actions

   Following this closely — we hit the identical wall from the memory side, and I'd like to add a real-world data point in favour of option 1.

   Who we are. Awareness is an open-source (Apache-2.0), local-first persistent-memory library for coding agents: Markdown + SQLite FTS5/hybrid retrieval, works offline, no account. We ship @awareness.market/opencode-plugin plus a local daemon (MCP + REST). https://awareness.market · https://github.com/everest-an/Awareness-SDK

   The wall, from our side. A memory plugin's whole job is to keep the active window small by holding long-lived project knowledge outside the transcript and pulling only what is relevant back in. In experimental.session.compacting we currently do exactly what you describe: we inject a structured handoff into output.context[] (objective / decisions / open tasks / constraints / files), because summary: string is the only return channel. It works — but:

   1. It's prose. The things we most need to survive — an exact constraint, a file path, a specific error string — survive only as well as they render into a paragraph.
   2. We're racing compaction, not performing it. Because we can't hand back the kept window as Message[], the host keeps compacting on its own schedule against the durable transcript — the same failure mode you note for the ctx.session.hook("context") workaround.

   So any memory backend is currently capped at "supply a better paragraph". That is exactly the ceiling #50862 names.

   +1 for option 1 — add messages?: ReadonlyArray<Message> to SessionCompactionResult and consume it in supplied() via the existing SessionProviderContext. It's the smallest change that lets a memory plugin be the compaction strategy rather than decorate the summarizer, and it inherits the provenance gating for free.

   Happy to help test. We maintain a working plugin + local daemon, so we can be a concrete integration test for whatever lands — including the "plugin returns nothing/garbage" edge you flagged (validating at install time, not read time, sounds right).

   Adjacent: #47810 is the trigger half — even with messages, required() can still fire first. Together they are the full picture.
5. everest-an commented on Oct 3, 2026

   

   everest-an

   on Oct 3, 2026

   More actions

   Small addendum from the memory-backend side, to make the case concrete:

   Our local-first memory library benchmarks at LongMemEval R@5 = 96.0% through its real retrieval pipeline (production E5 embeddings + live SQLite, zero LLM calls on the retrieval side). Open source, reproducible on any machine — benchmarks/longmemeval/run_f053_daemon_path.mjs in https://github.com/everest-an/Awareness-Market (site: https://awareness.market).

   So the blocker here isn't retrieval quality — it's purely that the compaction return channel only accepts prose. That's what makes option 1 (messages?: Message[]) an unlock rather than an optimisation: a memory backend could actually be the window strategy instead of rendering its answer into a paragraph.
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the detailed write-up. You're asking for the compaction hook to return a replacement window of Message[] that the next request uses unchanged, instead of only a summary string.

   Most of this has shipped since you opened the issue. Since v2.1.0 (#57260), SessionCompactionResult has an optional native field, and native.messages is treated as a replacement window:

   ctx.session.hook("compaction", async (event) => {
     const kept = pick(event.messages) // your scoring / pruning
     event.result = {
       summary: "…", // still required; shown in the UI and used where the window can't replay
       native: { messages: kept }, // replayed verbatim instead of `summary`
       // metadata: { keepID }, tokens: …  (optional)
     }
   })

   On current dev, the code does the following:

   • fromHook in packages/core/src/session/compaction.ts stores native on the compaction message.
   • packages/core/src/session/runner/to-llm-message.ts returns the decoded Message[] as-is in place of the <conversation-checkpoint> text.
   • Replay depends on the model: replayable in packages/core/src/session/history.ts only uses the window when the provider ID and model ID match the compaction's. After a model switch, the window isn't replayed.
   • A malformed window doesn't break the session: one that fails to decode as Message[] is skipped when history is read, instead of failing the history load.

   The docs for these fields are in #57276.

   Gaps that remain, as far as I can tell:

   • A bad window is caught when history is read, not when it's installed. It's dropped silently, the plugin gets no error, and the compaction is still recorded as completed.
   • There is no model-neutral option for a window from a hook.
   • Plugins still can't control when compaction runs.

   Maintainers will decide whether those gaps are worth pursuing or whether this can be closed as done. Please check whether native.messages on v2.1+ covers your pruning use case.

   Related issues:

   • [FEATURE]: V2 plugin support for managing context-window transitions #47810: the trigger half (a plugin taking over when compaction happens)
   • [FEATURE]: plugin session step hook for plugin-requested compaction #56744: plugin-requested compaction from a session step hook
   • docs(plugin): list compaction hook result fields #57276: docs for native.messages / metadata.keepID in the hook result
   • Compaction shrinking restores text removed by the compaction hook #54916: shrinking a compaction request restores text the compaction hook removed
   • refactor(core): move native compaction mechanisms into a plugin #49575: the internal native-compaction plugin you referenced