Repository navigation
[FEATURE]: Compaction: deterministic retention of user messages and a configurable compaction prompt #49463
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem / use case
After compaction the model only sees the summarizer's output plus a recent token tail. The original user messages and tool results are still in the session history, but they are no longer part of what the model sees. In practice this means requirements I stated at the start of a session, and constraints I set mid-session, stop being followed. Each subsequent compaction loses whatever the previous summary didn't carry forward, so degradation compounds over a long session.
There is also no config-level way to steer what must be preserved. The compaction summarizer runs without any system prompt or user-provided instructions. The experimental.session.compacting hook can replace the prompt, but it only receives { sessionID } — no per-invocation dynamic input — and it does not fire on the prune path.
Proposed solution
- Keep user messages visible verbatim after compaction (at minimum the first message, optionally pinned ones), independent of the LLM summary. Since the history rows are retained anyway, this is a projection decision rather than a storage change.
- A config-level way to supply persistent compaction instructions (for example a
compaction.promptorcompaction.instructionsfield), and/or giving the compacting hook per-invocation input so it can decide dynamically what must be carried forward. Ideally the same mechanism applies to the prune path, which today preserves nothing.
This request is about fidelity semantics, not about restructuring the compaction pipeline.
Alternatives considered
- The
experimental.session.compactinghook: covers prompt replacement only; no config-level support and no deterministic retention semantics. - AGENTS.md re-injection (fix(core): re-inject nested instructions after compaction #43723, merged) already covers on-disk constraint files. This request is about session content, not files.
Similar requests
I have searched for similar requests. #37551 (closed, not planned) proposed reinjecting a prompt; PR #38103 (closed, unmerged) attempted verbatim user messages; PR #45125 (open) proposes a restoration document, but even if merged it remains summarizer-mediated, not deterministic retention. #42574 (open) asks for configurable compaction instructions but not for user-message retention. #41358 (open) asks to keep the original user goal in the summary — again summarizer-mediated. #16512 and #16960 describe the same underlying pain. I believe this request is still distinct: it asks for deterministic (not summarizer-mediated) retention, plus a config surface for compaction instructions.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up! You're asking for two things. First, user messages (at least the first one, optionally pinned ones) should stay visible word for word after compaction, rather than depending on what the summary keeps. Second, there should be a config-level way to give compaction instructions, ideally applied to the prune path too. Maintainers will consider it.
The
experimental.session.compactinghook you describe is the v1 plugin API. In OpenCode v2 (@opencode/cli), the plugin API is broader:compactionhook receives the full compaction request (system,messages,options). A plugin can add its own instructions there, or setresultto supply the summary itself.contexthook can rewritemessagesbefore each agent request. That may let a plugin re-add your original requirements after compaction.There is no built-in
compaction.instructionsoption or user-message retention setting yet. That is what this request asks for.Related issues:
mooire733 commentedon Oct 28, 2026
I tested the V1 plugin and have now verified a V2 port on 2.2.0. In V2 the primary-request context hook can re-inject the ledger directly after compaction, so retention no longer depends on the summary preserving it; generate/title requests do not consume that pending injection. I also fixed the state-consumption and retry issues found while testing.
Two honest negatives: verbatim preservation in summaries was unreliable across compactions (the first reproduced the blocks, the second paraphrased them), and short-session baselines already retained constraints well, so this is not evidence of broad reliability gains.
I'd keep this request open: a local plugin demonstrates the mechanism, but it isn't a substitute for a supported, explicit policy for carrying requirements across compaction.