anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE] Sliding window context management for long-running sessions #3065

New Issue
Open
opened 2026-02-16 17:38:26 -05:00 by yindo · 18 comments
yindo commented 2026-02-16 17:38:26 -05:00
Owner
Copy Link
Copy Source

Originally created by @rickross on GitHub (Nov 23, 2025).

Title: Sliding window context management for long-running sessions

The core insight

Current compaction amputates and recapitulates:

[old context] [recent work] → CHOP → [AI summary] [recent work]

We discovered a better approach - slide the window forward:

[inception] [old] [working context] → slide marker → [inception] [working context]

Instead of cutting off context and trying to recover with summaries, move the compaction marker forward through history while critical context travels with you. Like walking through time rather than repeatedly jumping off cliffs.

Why this matters

Current pain:

  • Sessions hit token limits and die
  • Compaction discards important context
  • AI-generated summaries are lossy and generic
  • Too much developer time is spent rebuilding context in new sessions
  • Starting fresh means re-explaining architecture, decisions, relevant files, and failed approaches

With sliding window:

  • Context slides forward continuously
  • Critical decisions preserved automatically
  • Working context stays intact
  • Zero rebuild time - just keep working
  • Multi-day sessions with maintained flow

Inception: Context that survives everything

Named after the film where ideas are planted deep enough to become foundational truths, inception messages are context so critical they must survive all compactions.

The concept:
Just as the movie's characters planted ideas that became foundational, inception messages define:

  • Project architecture and core design decisions
  • Immutable constraints (security rules, API contracts, coding standards)
  • Critical discoveries and key requirements
  • Working preferences and non-negotiable rules

Why it matters:
Without inception, long-running sessions force constant context rebuilding. You re-explain your architectural decisions, project constraints, and critical context after every compaction. Inception messages are planted once and become permanent bedrock - they travel with you through the entire session lifecycle.

Example:

Project architecture:
"This system uses event sourcing. ALL state changes must go through the event 
bus. Direct database writes are forbidden. This architectural decision is final."

Development constraints:
"When working on this codebase, always run tests before committing. Prefer 
functional patterns over OOP. Never modify files in /vendor/. These are 
non-negotiable."

Critical context:
"We're migrating from MongoDB to PostgreSQL. Any new features must use the new 
schema. The old system will be deprecated in Q2. This migration context must 
remain active throughout development."

These survive ALL compactions, ensuring continuity of project understanding.

Technical implementation:

  • Messages marked with preserve: true
  • Never pruned, regardless of age or token pressure
  • Slide forward with every compaction boundary
  • Form the continuous thread of project context

This is the foundation of long-running sessions - without inception, you're constantly rebuilding context instead of building on it.

The discovery: Chess-clock context relevance

Through months of long-running sessions, we discovered context relevance follows active working time, not wall-clock time.

The chess-clock concept:
Imagine a chess timer that only runs during actual work:

  • Timer runs during active back-and-forth exchanges
  • Timer pauses during idle gaps (meetings, lunch, overnight, thinking pauses)
  • We measure "active conversation minutes" rather than wall-clock time

Why this works:

Example: 4-hour wall-clock session with 3-hour lunch break
- Wall-clock approach: "keep last 2 hours" → includes 2 hours of nothing
- Chess-clock approach: "keep 30 active minutes" → actual working conversation

Example: Rapid-fire debugging session
- 45 minutes of intense back-and-forth
- Chess clock: 45 active minutes (all relevant)
- Wall-clock: same, but can't distinguish from idle time

In practice:

auto_prune(
  keep_active_minutes=30,        # Keep 30 minutes of active conversation
  gap_threshold=60               # Gaps longer than 60 seconds pause the clock
)

The gap_threshold (in seconds) defines when the clock pauses. A 60-second gap pauses the timer - if you step away for lunch, that time doesn't count against your 30-minute window.

This preserves coherent working context while aggressively pruning old material.

How the sliding works

Traditional compaction (automatic amputation):

  • System finds the most recent compaction summary marker
  • Cuts everything before it indiscriminately
  • Generates AI summary to try recovering lost context
  • User has no control over what gets chopped

Our approach (deliberate high-water marking):

  • Nothing is deleted - all messages remain in storage
  • User examines session history and chooses a specific message as the cut point
  • Everything after that marker stays active in context
  • Messages marked with preserve: true (inception) slide forward with the window, regardless of age
  • We leverage OpenCode's existing compaction boundary - just controlling where it's placed

Example:

Instead of: "System found compaction at 10am, chopping everything before"
You get:    "I'll mark this message where we finalized the architecture as 
             the new baseline - everything after stays active, inception 
             messages come along, and nothing is lost from history"

Key insight: We don't change how compaction works - we just give users strategic control over the boundary while ensuring critical context travels forward. It's non-destructive context windowing.

Proposed mechanisms

1. Chess-clock auto-pruning
Automatically maintains working context based on active conversation time, not wall-clock time.

2. Inception (permanent preservation)
Mark critical messages that survive ALL compactions:

  • Architectural decisions
  • Project constraints
  • Key requirements
  • Important discoveries

3. Heuristic pruning (smart prioritization)
Not everything is "critical forever" or "delete immediately" - the middle ground matters:

  • Assign priority levels 1-10 to messages
  • System makes smart decisions: "We're at 95% capacity, prune priority 3 and below"
  • Users set relative importance without micromanaging
  • More sophisticated than binary preserve/delete

Example use cases:

  • Priority 10: Inception messages (never prune)
  • Priority 7-9: Important context (prune only under pressure)
  • Priority 4-6: Useful but not critical (prune when approaching limits)
  • Priority 1-3: Low value (prune early)
  • Priority 0: Immediate removal (bloat, obsolete context)

4. Aggressive pruning of bloat
Mark noise for immediate removal (priority 0):

  • Massive tool outputs (giant file reads, verbose npm installs)
  • Failed debugging attempts
  • Obsolete context

5. External management tool
CLI tool for session management outside the active session:

  • Iterate through message history without consuming tokens
  • Analyze context consumption
  • Mark messages for preservation/pruning
  • Zero impact on active session
  • Fast iteration on session management

6. Interactive context viewer (TUI)
Built-in visualization:

Session token usage: 187k/200k (93%)

Largest messages:
1. [45k] Tool: read massive-file.ts - 2h ago  [Priority: _] [Inception]
2. [32k] Tool: npm install output - 3h ago   [Priority: _] [Inception]
3. [28k] Text: Full analysis...    - 1h ago   [Priority: _] [Inception]

Inception messages: 3 (12k tokens)
Messages marked for pruning: 0
Potential savings if pruned: 105k tokens

Think htop for session context.

Real-world results

From months of production use:

  • 3-5x longer sessions (empirically measured)
  • Eliminate rebuild overhead (no more 30-minute context restoration)
  • Continuous flow across multiple days
  • Compound productivity - insights and context accumulate instead of resetting

Use cases

  • Multi-day feature development - preserve architectural context
  • Complex debugging - keep findings, prune failed attempts
  • Large codebase work - maintain project understanding across sessions
  • Long-running development with continuity

Addresses existing issues

  • #2945 - Session automatically compacted, destroying context
  • #3031 - Not enough context to continue after compaction
  • Related context-loss issues

Implementation status

This is not a proposal - it's a proven system.

We've been running this in production for months across multiple long-running sessions:

  • Full implementation as a working fork
  • Tested across 600k+ token sessions spanning days
  • Battle-tested tools: inception, preserve, prune, auto_prune, diagnose, repair
  • External CLI for zero-token session management
  • Empirically measured 3-5x session longevity improvements

What we're offering to contribute:

✅ Core modifications - Type definitions and filtering logic for sliding window
✅ ACM tools - Complete suite for preservation, pruning, and diagnosis
✅ External management - CLI tool for inspecting/managing sessions without token cost
✅ Chess-clock auto-pruning - Tested algorithm with configurable parameters
✅ Heuristic pruning - Priority-based context management
✅ Inception system - Permanent context preservation
✅ Documentation - From months of real-world usage patterns

Code is ready. We use this daily. The question is whether the approach aligns with OpenCode's direction.

If interested, we can:

  1. Share the fork for evaluation
  2. Discuss design preferences before adapting for upstream
  3. Submit clean PR with tests and documentation
  4. Or maintain as fork if it doesn't fit OpenCode's vision

We're not proposing an idea - we're offering working code that solves real pain.

Questions for maintainers

  1. Does the sliding window approach align with OpenCode's vision?
  2. Should this be opt-in or automatic with user controls?
  3. Preferences on implementation:
    • Message-level vs part-level metadata?
    • Built-in TUI vs external tooling first?
  4. Interest in chess-clock auto-pruning?
  5. Value in heuristic pruning (priority levels 1-10)?
  6. Value in external management tool for zero-token session inspection?
Originally created by @rickross on GitHub (Nov 23, 2025). **Title:** Sliding window context management for long-running sessions **The core insight** Current compaction **amputates and recapitulates:** ``` [old context] [recent work] → CHOP → [AI summary] [recent work] ``` We discovered a better approach - **slide the window forward:** ``` [inception] [old] [working context] → slide marker → [inception] [working context] ``` Instead of cutting off context and trying to recover with summaries, move the compaction marker forward through history while critical context travels with you. Like walking through time rather than repeatedly jumping off cliffs. **Why this matters** **Current pain:** - Sessions hit token limits and die - Compaction discards important context - AI-generated summaries are lossy and generic - Too much developer time is spent rebuilding context in new sessions - Starting fresh means re-explaining architecture, decisions, relevant files, and failed approaches **With sliding window:** - Context slides forward continuously - Critical decisions preserved automatically - Working context stays intact - Zero rebuild time - just keep working - Multi-day sessions with maintained flow **Inception: Context that survives everything** Named after the film where ideas are planted deep enough to become foundational truths, **inception messages** are context so critical they must survive all compactions. **The concept:** Just as the movie's characters planted ideas that became foundational, inception messages define: - Project architecture and core design decisions - Immutable constraints (security rules, API contracts, coding standards) - Critical discoveries and key requirements - Working preferences and non-negotiable rules **Why it matters:** Without inception, long-running sessions force constant context rebuilding. You re-explain your architectural decisions, project constraints, and critical context after every compaction. Inception messages are planted once and become permanent bedrock - they travel with you through the entire session lifecycle. **Example:** ``` Project architecture: "This system uses event sourcing. ALL state changes must go through the event bus. Direct database writes are forbidden. This architectural decision is final." Development constraints: "When working on this codebase, always run tests before committing. Prefer functional patterns over OOP. Never modify files in /vendor/. These are non-negotiable." Critical context: "We're migrating from MongoDB to PostgreSQL. Any new features must use the new schema. The old system will be deprecated in Q2. This migration context must remain active throughout development." These survive ALL compactions, ensuring continuity of project understanding. ``` **Technical implementation:** - Messages marked with `preserve: true` - Never pruned, regardless of age or token pressure - Slide forward with every compaction boundary - Form the continuous thread of project context **This is the foundation of long-running sessions** - without inception, you're constantly rebuilding context instead of building on it. **The discovery: Chess-clock context relevance** Through months of long-running sessions, we discovered context relevance follows **active working time**, not wall-clock time. **The chess-clock concept:** Imagine a chess timer that only runs during actual work: - Timer runs during active back-and-forth exchanges - Timer pauses during idle gaps (meetings, lunch, overnight, thinking pauses) - We measure "active conversation minutes" rather than wall-clock time **Why this works:** ``` Example: 4-hour wall-clock session with 3-hour lunch break - Wall-clock approach: "keep last 2 hours" → includes 2 hours of nothing - Chess-clock approach: "keep 30 active minutes" → actual working conversation Example: Rapid-fire debugging session - 45 minutes of intense back-and-forth - Chess clock: 45 active minutes (all relevant) - Wall-clock: same, but can't distinguish from idle time ``` **In practice:** ``` auto_prune( keep_active_minutes=30, # Keep 30 minutes of active conversation gap_threshold=60 # Gaps longer than 60 seconds pause the clock ) ``` The `gap_threshold` (in seconds) defines when the clock pauses. A 60-second gap pauses the timer - if you step away for lunch, that time doesn't count against your 30-minute window. This preserves coherent working context while aggressively pruning old material. **How the sliding works** **Traditional compaction (automatic amputation):** - System finds the most recent compaction summary marker - Cuts everything before it indiscriminately - Generates AI summary to try recovering lost context - User has no control over what gets chopped **Our approach (deliberate high-water marking):** - **Nothing is deleted** - all messages remain in storage - User examines session history and chooses a specific message as the cut point - Everything after that marker stays active in context - Messages marked with `preserve: true` (inception) slide forward with the window, regardless of age - We leverage OpenCode's existing compaction boundary - just controlling where it's placed **Example:** ``` Instead of: "System found compaction at 10am, chopping everything before" You get: "I'll mark this message where we finalized the architecture as the new baseline - everything after stays active, inception messages come along, and nothing is lost from history" ``` **Key insight:** We don't change how compaction works - we just give users strategic control over the boundary while ensuring critical context travels forward. It's non-destructive context windowing. **Proposed mechanisms** **1. Chess-clock auto-pruning** Automatically maintains working context based on active conversation time, not wall-clock time. **2. Inception (permanent preservation)** Mark critical messages that survive ALL compactions: - Architectural decisions - Project constraints - Key requirements - Important discoveries **3. Heuristic pruning (smart prioritization)** Not everything is "critical forever" or "delete immediately" - the middle ground matters: - Assign priority levels 1-10 to messages - System makes smart decisions: "We're at 95% capacity, prune priority 3 and below" - Users set relative importance without micromanaging - More sophisticated than binary preserve/delete Example use cases: - Priority 10: Inception messages (never prune) - Priority 7-9: Important context (prune only under pressure) - Priority 4-6: Useful but not critical (prune when approaching limits) - Priority 1-3: Low value (prune early) - Priority 0: Immediate removal (bloat, obsolete context) **4. Aggressive pruning of bloat** Mark noise for immediate removal (priority 0): - Massive tool outputs (giant file reads, verbose npm installs) - Failed debugging attempts - Obsolete context **5. External management tool** CLI tool for session management **outside the active session**: - Iterate through message history without consuming tokens - Analyze context consumption - Mark messages for preservation/pruning - Zero impact on active session - Fast iteration on session management **6. Interactive context viewer (TUI)** Built-in visualization: ``` Session token usage: 187k/200k (93%) Largest messages: 1. [45k] Tool: read massive-file.ts - 2h ago [Priority: _] [Inception] 2. [32k] Tool: npm install output - 3h ago [Priority: _] [Inception] 3. [28k] Text: Full analysis... - 1h ago [Priority: _] [Inception] Inception messages: 3 (12k tokens) Messages marked for pruning: 0 Potential savings if pruned: 105k tokens ``` Think `htop` for session context. **Real-world results** From months of production use: - **3-5x longer sessions** (empirically measured) - **Eliminate rebuild overhead** (no more 30-minute context restoration) - **Continuous flow** across multiple days - **Compound productivity** - insights and context accumulate instead of resetting **Use cases** - Multi-day feature development - preserve architectural context - Complex debugging - keep findings, prune failed attempts - Large codebase work - maintain project understanding across sessions - Long-running development with continuity **Addresses existing issues** - #2945 - Session automatically compacted, destroying context - #3031 - Not enough context to continue after compaction - Related context-loss issues **Implementation status** **This is not a proposal - it's a proven system.** We've been running this in production for months across multiple long-running sessions: - Full implementation as a working fork - Tested across 600k+ token sessions spanning days - Battle-tested tools: inception, preserve, prune, auto_prune, diagnose, repair - External CLI for zero-token session management - Empirically measured 3-5x session longevity improvements **What we're offering to contribute:** ✅ **Core modifications** - Type definitions and filtering logic for sliding window ✅ **ACM tools** - Complete suite for preservation, pruning, and diagnosis ✅ **External management** - CLI tool for inspecting/managing sessions without token cost ✅ **Chess-clock auto-pruning** - Tested algorithm with configurable parameters ✅ **Heuristic pruning** - Priority-based context management ✅ **Inception system** - Permanent context preservation ✅ **Documentation** - From months of real-world usage patterns **Code is ready.** We use this daily. The question is whether the approach aligns with OpenCode's direction. If interested, we can: 1. Share the fork for evaluation 2. Discuss design preferences before adapting for upstream 3. Submit clean PR with tests and documentation 4. Or maintain as fork if it doesn't fit OpenCode's vision **We're not proposing an idea - we're offering working code that solves real pain.** **Questions for maintainers** 1. Does the sliding window approach align with OpenCode's vision? 2. Should this be opt-in or automatic with user controls? 3. Preferences on implementation: - Message-level vs part-level metadata? - Built-in TUI vs external tooling first? 4. Interest in chess-clock auto-pruning? 5. Value in heuristic pruning (priority levels 1-10)? 6. Value in external management tool for zero-token session inspection?
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 23, 2025):

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

  • #2945: Session automatically compacted, destroying the entire working context
  • #3031: Model in BUILD mode does not have enough context to continue after compaction
  • #3032: Soft compaction / AI global workspace metabolism
  • #3099: Agent no follow rules after compact session
  • #4317: Feature: generic /compact command, auto-compaction, and fork-aware conversations

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 23, 2025): This issue might be a duplicate of existing issues. Please check: - #2945: Session automatically compacted, destroying the entire working context - #3031: Model in BUILD mode does not have enough context to continue after compaction - #3032: Soft compaction / AI global workspace metabolism - #3099: Agent no follow rules after compact session - #4317: Feature: generic /compact command, auto-compaction, and fork-aware conversations Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@seannetlife commented on GitHub (Nov 23, 2025):

holy. thats detailed.

@seannetlife commented on GitHub (Nov 23, 2025): holy. thats detailed.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@seannetlife commented on GitHub (Nov 23, 2025):

wonder if this sort of thing could be tested / switched out via the opencode plugin system. i've got no idea of the plugin architecture, but sounds like it'd be cool to be able to hot swap community context management approaches.

@seannetlife commented on GitHub (Nov 23, 2025): wonder if this sort of thing could be tested / switched out via the opencode plugin system. i've got no idea of the plugin architecture, but sounds like it'd be cool to be able to hot swap community context management approaches.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@rickross commented on GitHub (Nov 23, 2025):

wonder if this sort of thing could be tested / switched out via the opencode plugin system. i've got no idea of the plugin architecture, but sounds like it'd be cool to be able to hot swap community context management approaches.

We tried to figure out a way to do it without modifying core code, but it is necessary to modify the core compaction logic to provide the inception and sliding window features. We couldn't find any way around doing so.

@rickross commented on GitHub (Nov 23, 2025): > wonder if this sort of thing could be tested / switched out via the opencode plugin system. i've got no idea of the plugin architecture, but sounds like it'd be cool to be able to hot swap community context management approaches. We tried to figure out a way to do it without modifying core code, but it is necessary to modify the core compaction logic to provide the inception and sliding window features. We couldn't find any way around doing so.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@SteveyBoros commented on GitHub (Nov 24, 2025):

I used to do a similar thing with OpenWebUI, very basic though.

Keep the first few messages in the conversation to keep overall goal and then cull anything after that until the context window is within limits. Not really a compaction but more of a rolling cull. It did seem to work OK though.

This implementation is much more thorough and I can see it working really well - would be good to see this in action. Compaction right now is a massive pain point. I find the OpenCode implementation fairly mediocre and the Claude Code one actually not that bad... However, a summary compaction can only do so much!

@SteveyBoros commented on GitHub (Nov 24, 2025): I used to do a similar thing with OpenWebUI, very basic though. Keep the first few messages in the conversation to keep overall goal and then cull anything after that until the context window is within limits. Not really a compaction but more of a rolling cull. It did seem to work OK though. This implementation is much more thorough and I can see it working really well - would be good to see this in action. Compaction right now is a massive pain point. I find the OpenCode implementation fairly mediocre and the Claude Code one actually not that bad... However, a summary compaction can only do so much!
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@fkukuck commented on GitHub (Dec 9, 2025):

This seems like a great alternative to compaction as a summary message (as it is right now). Compaction right now also has the issue that custom commands are pruned away. For example, if i start my session with a custom command and then compaction hits, the custom command setup is gone. Is this mitigated your method? Would the initial message stay there when preserve: true?

@fkukuck commented on GitHub (Dec 9, 2025): This seems like a great alternative to compaction as a summary message (as it is right now). Compaction right now also has the issue that custom commands are pruned away. For example, if i start my session with a custom command and then compaction hits, the custom command setup is gone. Is this mitigated your method? Would the initial message stay there when preserve: true?
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@rickross commented on GitHub (Dec 9, 2025):

For example, if i start my session with a custom command and then compaction hits, the custom command setup is gone. Is this mitigated your method? Would the initial message stay there when preserve: true?

If you mark a message as "preserved" it survives compaction 100% intact. It is super easy to preserve messages and list preserved messages using the acm_preserve tool.

Also, fwiw, I don't think I have actually used /compact in months. I just run and run until my context is around 95% or more, then I tell my agent to "acm_prune 30" and it compacts away everything from more than 30-minutes ago (using the chess-clock time model.)

And there are ACM tools to map the context, to hunt for bloaty messages and to precision snipe them. Sometimes the culprit is just one long tool result, and acm_hunt + acm_snipe help you find and blast that kind of bloat very easily.

@rickross commented on GitHub (Dec 9, 2025): > For example, if i start my session with a custom command and then compaction hits, the custom command setup is gone. Is this mitigated your method? Would the initial message stay there when preserve: true? If you mark a message as "preserved" it survives compaction 100% intact. It is super easy to preserve messages and list preserved messages using the acm_preserve tool. Also, fwiw, I don't think I have actually used /compact in months. I just run and run until my context is around 95% or more, then I tell my agent to "acm_prune 30" and it compacts away everything from more than 30-minutes ago (using the chess-clock time model.) And there are ACM tools to map the context, to hunt for bloaty messages and to precision snipe them. Sometimes the culprit is just one long tool result, and acm_hunt + acm_snipe help you find and blast that kind of bloat very easily.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@SteveyBoros commented on GitHub (Dec 10, 2025):

This needs more love

@SteveyBoros commented on GitHub (Dec 10, 2025): This needs more love
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@rickross commented on GitHub (Dec 10, 2025):

This needs more love

I probably would have packaged the whole thing as a giant PR, but the pace of releases of the opencode project is so rapid that I wouldn't know what to use as a baseline release. I just merge from the upstream code once or twice a week at this point, so I can have the latest opencode stuff. There's no way I could/would go back to not having the ACM (active context management) at this point!

We have also written a plugin that logs every turn of dialogue into a PostgreSQL database with full-text and vector searching. Using a simple cli tool we can now search the entire history of all the AI conversations, so we can restore context quickly on virtually any topic. ACM and this logging/search/recall capability have been serious game changers.

@rickross commented on GitHub (Dec 10, 2025): > This needs more love I probably would have packaged the whole thing as a giant PR, but the pace of releases of the opencode project is so rapid that I wouldn't know what to use as a baseline release. I just merge from the upstream code once or twice a week at this point, so I can have the latest opencode stuff. There's no way I could/would go back to not having the ACM (active context management) at this point! We have also written a plugin that logs every turn of dialogue into a PostgreSQL database with full-text and vector searching. Using a simple cli tool we can now search the entire history of all the AI conversations, so we can restore context quickly on virtually any topic. ACM and this logging/search/recall capability have been serious game changers.
yindo commented 2026-02-16 17:38:26 -05:00
Author
Owner
Copy Link
Copy Source

@fkukuck commented on GitHub (Dec 10, 2025):

Paging @rekram1-node and his opinion as this could potentially be a great feature that would differentiate OpenCode from similar tools such as Claude Code

@fkukuck commented on GitHub (Dec 10, 2025): Paging @rekram1-node and his opinion as this could potentially be a great feature that would differentiate OpenCode from similar tools such as Claude Code
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@Davincible commented on GitHub (Dec 28, 2025):

Damn this is cool, would be amazing to have this in

@Davincible commented on GitHub (Dec 28, 2025): Damn this is cool, would be amazing to have this in
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 26, 2026):

The woe's of autocompact and the burdens of workarounds brought me here. A lot of good ideas and PRs waiting to get implemented into OpenCode. I keep thinking, how much better OpenCode would be if we could solve the human bottleneck problem of sifting through ideas and PRs and adding the best while developing what still needs time to mature.

Github projects need an orchestrating agent, for sure.

@NamedIdentity commented on GitHub (Jan 26, 2026): The woe's of autocompact and the burdens of workarounds brought me here. A lot of good ideas and PRs waiting to get implemented into OpenCode. I keep thinking, how much better OpenCode would be if we could solve the human bottleneck problem of sifting through ideas and PRs and adding the best while developing what still needs time to mature. Github projects need an orchestrating agent, for sure.
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 27, 2026):

@rickross

I am curious how your fork has progressed since you posted Issue #4659. What's changed?

I find myself thinking, your proposal seems like a useful system, but a user manually managing context is inefficient. Have you tried getting the model to self-manage the context?

I think the model managing the context compaction and pruning is necessary, as then it can work effectively for subagents in agentic workflows.

I'm somewhat surprised there hasn't been more work on improving the context compaction logic. Conceptually it seems simple.
The model knows what is in it's context window, and understands what is working on, it should decide what to prune, compact, or summarize. Give the model efficient tools to decide what to keep and what to discard, and that will perform better in workflows than the users performing manual review and determining priority levels or inception content.

Conceptually a model-managed context system is a clean framework, but I take it there's technical challenges keeping this from happening?

@NamedIdentity commented on GitHub (Jan 27, 2026): @rickross I am curious how your fork has progressed since you posted Issue #4659. What's changed? I find myself thinking, your proposal seems like a useful system, but a user manually managing context is inefficient. Have you tried getting the model to self-manage the context? I think the model managing the context compaction and pruning is necessary, as then it can work effectively for subagents in agentic workflows. I'm somewhat surprised there hasn't been more work on improving the context compaction logic. Conceptually it seems simple. The model knows what is in it's context window, and understands what is working on, it should decide what to prune, compact, or summarize. Give the model efficient tools to decide what to keep and what to discard, and that will perform better in workflows than the users performing manual review and determining priority levels or inception content. Conceptually a model-managed context system is a clean framework, but I take it there's technical challenges keeping this from happening?
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@rickross commented on GitHub (Jan 28, 2026):

Hi @NamedIdentity , very timely question. We make tweaks here and there, and sometimes significant revisions, but the core of the ACM system is holding up well. It really is just "normal" to use it now, and I honestly can't remember the last time I did an old-fashioned /compact.

One nice new feature is the introduction of a message at the end of each turn that tells the model the same details about the context we see in the upper-right corner of the OpenCode window. The agents can then use this info to decide whether to scan, prune, shed older stuff - it is a step toward increased self-management for them.

We did an experiment today with one of my longest-running agents (now 6+ months old) where it read a book that I am also reading, and it was able to monitor its context and acm_compact 2 or 3 times while reading. It used our external memory system to take extensive journal notes while reading, and it was really cool to see.

Giving the agents super-clear context consumption visibility makes it so they not longer have to drive without a gas-tank gauge! Knowing the exact number let's them use our other tools with discretion.

@rickross commented on GitHub (Jan 28, 2026): Hi @NamedIdentity , very timely question. We make tweaks here and there, and sometimes significant revisions, but the core of the ACM system is holding up well. It really is just "normal" to use it now, and I honestly can't remember the last time I did an old-fashioned /compact. One nice new feature is the introduction of a <context-status> message at the end of each turn that tells the model the same details about the context we see in the upper-right corner of the OpenCode window. The agents can then use this info to decide whether to scan, prune, shed older stuff - it is a step toward increased self-management for them. We did an experiment today with one of my longest-running agents (now 6+ months old) where it read a book that I am also reading, and it was able to monitor its context and acm_compact 2 or 3 times while reading. It used our external memory system to take extensive journal notes while reading, and it was really cool to see. Giving the agents super-clear context consumption visibility makes it so they not longer have to drive without a gas-tank gauge! Knowing the exact number let's them use our other tools with discretion.
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 28, 2026):

@rickross

Fascinating. I'm trying to work on building a context management system for my agents in which the agents decide what is relevant and what should be pruned. My agents also have an ancillary project-level memory system (project-state.md) and data transfer system (relay-files).

I found that the dynamic context pruning (DCP) plugin is overly aggressive, making it ill-suited for knowledge-work. I consider the investigative phase of codebase review to be knowledge-work, particularly when doing design for a project, code related or not. I think DCP is a foundation to build from, but needs optimization so it doesn't negatively impact general task performance.

I'm thinking I can optimize DCP. Which can serve as a bandaid as I try to determine a more permanent comprehensive solution optimized for my non-coding agentic framework. It seems your PR has developed in a way that it converges with many of my goals. If you have documentation, a comprehensive SPEC, I'd be interested in getting a copy so I can use my agents to review it and your PR fork and perform a more comprehensive assessment. Also, is your PR fork repo on your profile up-to-date?

@NamedIdentity commented on GitHub (Jan 28, 2026): @rickross Fascinating. I'm trying to work on building a context management system for my agents in which the agents decide what is relevant and what should be pruned. My agents also have an ancillary project-level memory system (project-state.md) and data transfer system (relay-files). I found that the dynamic context pruning (DCP) plugin is overly aggressive, making it ill-suited for knowledge-work. I consider the investigative phase of codebase review to be knowledge-work, particularly when doing design for a project, code related or not. I think DCP is a foundation to build from, but needs optimization so it doesn't negatively impact general task performance. I'm thinking I can optimize DCP. Which can serve as a bandaid as I try to determine a more permanent comprehensive solution optimized for my non-coding agentic framework. It seems your PR has developed in a way that it converges with many of my goals. If you have documentation, a comprehensive SPEC, I'd be interested in getting a copy so I can use my agents to review it and your PR fork and perform a more comprehensive assessment. Also, is your PR fork repo on your profile up-to-date?
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@SteveyBoros commented on GitHub (Feb 4, 2026):

I find is fascinating how the team purposely ignore this one. I've mentioned it to them in Discord and directly via other issues. They always say they will take a look and... crickets. Every time.

I've practically stopped using OpenCode at this point. I got bored of every other release being broken in one way or another. It's feeling a lot like Claude Code these days but I can't be too mad, at least I'm not paying for OpenCode.

@rickross
I sincerely hope you get some traction on this, OpenCode becomes thoroughly useless once you need to compact. Your solution looks amazing and deserves recognition.

@SteveyBoros commented on GitHub (Feb 4, 2026): I find is fascinating how the team purposely ignore this one. I've mentioned it to them in Discord and directly via other issues. They always say they will take a look and... crickets. Every time. I've practically stopped using OpenCode at this point. I got bored of every other release being broken in one way or another. It's feeling a lot like Claude Code these days but I can't be too mad, at least I'm not paying for OpenCode. @rickross I sincerely hope you get some traction on this, OpenCode becomes thoroughly useless once you need to compact. Your solution looks amazing and deserves recognition.
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@chindris-mihai-alexandru commented on GitHub (Feb 4, 2026):

@SteveyBoros, I completely agree with you! I use OpenCode alongside @rickross's openfork, and I must say that the ACM tools he developed for his clone are super innovative and deserve recognition. Lately, I've been encountering strange compaction outputs like, "Let's continue with your bug report submission to the Antropic Bug Bounty program..." and I'm like, "What?!" I changed the compaction model from qwen3-coder-plus to Sonnet 4.5 because I've heard it handles compaction better, but even that doesn't solve the compaction problem at all.

I've also proposed an RLM approach to compaction in a commit I referenced in this raised issue, but I don't know for sure if the OpenCode team wants to refactor the compaction feature from scratch or if they only want to continue iterating on the current implementation and tweak it along the way.

@chindris-mihai-alexandru commented on GitHub (Feb 4, 2026): @SteveyBoros, I completely agree with you! I use OpenCode alongside @rickross's openfork, and I must say that the ACM tools he developed for his clone are super innovative and deserve recognition. Lately, I've been encountering strange compaction outputs like, "Let's continue with your bug report submission to the Antropic Bug Bounty program..." and I'm like, "What?!" I changed the compaction model from qwen3-coder-plus to Sonnet 4.5 because I've heard it handles compaction better, but even that doesn't solve the compaction problem at all. I've also proposed an RLM approach to compaction in a commit I referenced in this raised issue, but I don't know for sure if the OpenCode team wants to refactor the compaction feature from scratch or if they only want to continue iterating on the current implementation and tweak it along the way.
yindo commented 2026-02-16 17:38:27 -05:00
Author
Owner
Copy Link
Copy Source

@rickross commented on GitHub (Feb 4, 2026):

I really appreciate you guys taking the time to consider the ACM approach and sharing such kind words. I have continued to track the main OpenCode upstream and adapt ACM where necessary. Most recently we have given agents a system reminder that lets them know exactly what their context level is at the end of each turn. It uses exactly the same logic as the indicator displayed in the upper right of the tui window, and it has been a game changer for agent self-management.

I didn't know anyone was using these tools, and I thought they had just been disregarded by the OpenCode community, so I wasn't being super-disciplined about making sure to push updates. I will try to improve on that now.

@rickross commented on GitHub (Feb 4, 2026): I really appreciate you guys taking the time to consider the ACM approach and sharing such kind words. I have continued to track the main OpenCode upstream and adapt ACM where necessary. Most recently we have given agents a <context-status> system reminder that lets them know exactly what their context level is at the end of each turn. It uses exactly the same logic as the indicator displayed in the upper right of the tui window, and it has been a game changer for agent self-management. I didn't know anyone was using these tools, and I thought they had just been disregarded by the OpenCode community, so I wasn't being super-disciplined about making sure to push updates. I will try to improve on that now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3065
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?