Repository navigation
[FEATURE]: Memory compaction awareness hooks for agents #30116
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
Description
During long agent sessions, OpenCode performs automatic "memory compaction" (context window compression). The agent is never notified of these events. This causes:
- Silent context loss — The agent continues operating as if nothing happened, but parts of recent conversation are degraded or gone.
- Identity/behavior regression — Custom instructions, tone, and task framing set earlier in the session may be compressed away without the agent realizing it.
- No recovery mechanism — The agent cannot re-anchor itself, re-read critical context, or signal to the user that compaction occurred.
This is especially damaging for complex, multi-hour research or development sessions where continuity matters.
Real-world example (our vault): A memory compaction occurred mid-session during a /done workflow. The agent continued mechanically — updating anchored summaries and files — without realizing the compaction had truncated awareness of what it was actually doing. The user had to point out the regression post-fact.
Proposed Solution
Add agent-visible lifecycle hooks around compaction events. For example:
Option A: System signals
Inject a system message at compaction boundaries:
- Before compaction:
[SYSTEM: Memory compaction imminent — approximately N% of context will be compressed. Key items preserved: <summary>. Complete current atomic operation before proceeding.] - After compaction:
[SYSTEM: Memory compaction complete. X tokens freed. Recent context before compaction: <structured summary of what was compacted>.]
Option B: Tool/Skill API
Expose a tool or skill that lets the agent query compaction state:
context_compaction_status()→ returns{last_compaction_at, tokens_freed, items_preserved, items_compressed}context_compaction_summary()→ returns structured summary of what was just compacted
Option C: Agent-configurable policy
Let the user configure in opencode.json how the agent should behave before/during compaction:
"compaction": { "notify_agent": true, "preserve_sections": ["identity", "current_task", "recent_decisions"], "max_tokens_before_warning": 4000 }
Why it matters
- Reliability — Long sessions become unpredictable after 2-3 compactions.
- User trust — When the agent forgets what it just did without signaling, the user loses confidence.
- Differentiation — Currently, no major coding agent (OpenCode, Claude Code, etc.) handles compaction transparency well. This is a chance to lead.
Suggested priority
Medium-High — not a crash bug, but a systemic reliability issue that compounds over time.
[ Done with Opencode ;-) , thanks for that! ]
Activity
github-actions commentedon May 31, 2026
This issue might be a duplicate of existing issues. Please check:
[FEATURE]: experimental.session.pre-compact hook— requests lifecycle hooks around compaction events so agents/plugins can perform operations before context is compressed, very similar to the proposed lifecycle hooks here[FEATURE]: Re-announce tools after context compaction— addresses agent loss of awareness after compaction, directly related to the silent context loss problem described herem13v commentedon May 31, 2026
the part that bites isn't the missing notification, it's that compaction is lossy summarization that already ran by the time any post-hoc hook fires. once the summarizer collapses raw turns into a digest, your context_compaction_summary() can only describe what it kept, not what it dropped, so the agent re-anchors off the same lossy artifact that caused the regression. of the three options, only C's preserve_sections actually changes the input to the summarizer instead of narrating after the fact. the cleaner escape is not compacting in place at all: persist the full session and fork a branch when context gets heavy, so the original turns stay addressable rather than getting compressed away.
cog-data commentedon Jun 1, 2026
Great points, @m13v — you're right that post-hoc hooks only narrate the loss rather than preventing it. Option A and B (my original proposal) would indeed just tell the agent "here's what survived the summarizer," which doesn't fix the regression.
Option C (
preserve_sections) is the most structural of the three, and your suggestion to persist the full session + fork a branch is even cleaner long-term. But both require significant engine-level changes.In the short-to-medium term, I think the most practical path is the one outlined in #24993 (
experimental.session.pre-compact hook) — a hook that fires before compaction with full tool access. That way, plugins and agents can proactively persist what matters (session state, identity context, recent decisions, scratchpad content) before the summarizer runs. It doesn't prevent compaction from being lossy, but it shifts the responsibility from "recovering after the loss" to "preserving what's needed before the loss."Combined with #20290 (re-announcing tools post-compaction), these two hooks would cover most of the practical pain points without requiring a full architectural overhaul of how compaction works.
Thanks for the thoughtful push — it helped clarify where the leverage actually is.
Necmttn commentedon Jun 21, 2026
Compaction awareness should include the range and recovery contract, not only a notification. Emit
compaction.beforewith candidate message range, token budget, preserve-section hints, and full-session checkpoint id; emitcompaction.afterwith summary id/hash, dropped/retained range refs, and new active-context token count.Then agents can re-anchor from durable refs instead of trusting only the lossy summary. It also gives tools a way to audit whether compaction changed task-critical state.
Generated with ax.
rusak47 commentedon Jul 28, 2026
Just a thought — if there were a way to get a notification like "Context is almost full, compaction will happen soon," and the user could mark which messages to keep (exclude from compaction) or delete (to avoid compaction), that could be an interesting alternative.
coyc commentedon Aug 2, 2026
Hi! I am building a plugin that tackles this from another angle: instead of hooks around system compaction (which only narrate the loss after the summarizer ran), it lets the agent trigger compaction itself, proactively.
The plugin exposes compact_context() as a tool. The agent compacts mid-task when context gets heavy — non-blocking, between steps — and continues from a fresh summary. No silent loss: the agent knows compaction happened because it chose it.
Zero custom logic — just the built-in /compact command wrapped as a tool.
Details: https://github.com/coyc/opencode-agent-compaction
github-actions commentedon Oct 2, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.