Problem
lossless-claw currently runs proactive threshold compaction on the foreground turn path. In large or busy sessions, that can block the active user turn long enough to create long lane waits, make the main agent feel unresponsive, and delay subagent completion announce behind compaction work.
This is most visible in two real usage patterns:
- Worst case: one orchestrator plus up to 4 subagents, with both write-mode and read-mode LCM activity competing for the same session lane.
- Minimum heavy case: one orchestrator plus up to 4 agents reading LCM concurrently while proactive maintenance is queued or running.
The current behavior also hides maintenance state from users, so when compaction is happening they see only a stalled or slow turn, not a clear indication of what the system is doing.
Goal
Make proactive compaction debt-driven and visible, without allowing it to block foreground turns. Manual compaction, overflow recovery, and timeout recovery should remain synchronous when correctness requires it.
Acceptance Criteria
- Proactive threshold compaction no longer runs inline in foreground
afterTurn.
- Compaction requests are coalesced per session/conversation instead of stacking.
- The plugin tracks and exposes maintenance state:
- pending
- running
- last success
- last failure
- Read-only LCM operations remain usable while compaction debt is pending or running.
- Subagent announce flow is no longer starved by proactive compaction.
- Manual, overflow, and timeout recovery compaction remain synchronous.
- Users get subtle visibility only when maintenance is long-running or fails.
Validation Notes
- Reproduce with an orchestrator plus multiple agents/subagents under mixed read/write pressure.
- Verify the foreground turn returns promptly while compaction debt is pending.
- Verify the system surfaces maintenance state without turning it into noisy chat output.
- Verify manual/overflow/timeout compaction still behaves synchronously.
Problem
lossless-clawcurrently runs proactive threshold compaction on the foreground turn path. In large or busy sessions, that can block the active user turn long enough to create long lane waits, make the main agent feel unresponsive, and delay subagent completion announce behind compaction work.This is most visible in two real usage patterns:
The current behavior also hides maintenance state from users, so when compaction is happening they see only a stalled or slow turn, not a clear indication of what the system is doing.
Goal
Make proactive compaction debt-driven and visible, without allowing it to block foreground turns. Manual compaction, overflow recovery, and timeout recovery should remain synchronous when correctness requires it.
Acceptance Criteria
afterTurn.Validation Notes