#Double Compaction

1 messages · Page 1 of 1 (latest)

tardy valley
#

I'm not seeing a ton of chatter about it on here but I found an issue submitted on GitHub about it. Is anyone experiencing double compactions? Every compaction event is followed by another one within 30 seconds to 10 minutes, depending on the events happening before the first compaction and after. The first compaction seems succeessful, but another one is fired right after the first and essentially lobotomizes the model.

Super weird behavior and I'm wondering if it's a config issue or just a straight up bug.

tawny oracleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

bold phoenixBOT
#

That can happen “by design” in OpenClaw, because auto-compaction is allowed to immediately retry the original request after it compacts. If the retry still trips the context-limit logic (or the token estimate still thinks it’s too close), you can end up with what looks like a second compaction shortly after the first.

A few common reasons it turns into “double compaction” (and feels like a lobotomy):

  • Compaction + retry loop: the first compaction ends with willRetry=true and the runner re-attempts the prompt; if it still overflows / is near-overflow → compacts again.
  • Reserve too high for the model: if you’re on a smaller-context model and agents.defaults.compaction.reserveTokensFloor is large, the system may keep deciding it needs to compact aggressively (or repeatedly).
  • Huge tool results / logs: one oversized tool result can keep you above the limit even after a “successful” compaction (then it tries fallback truncation / re-compaction).
  • Memory flush turn: if compaction.memoryFlush.enabled is on, there’s an extra silent turn before compaction; depending on what you’re watching, it can look like “compaction happened twice” even when it’s actually “flush + compact + retry”.

How to confirm which case you’re in:

  1. Check the gateway logs around the event and see whether the first compaction ends with a retry.
    • openclaw logs --follow
  2. Paste the few lines around the compactions (look for auto_compaction_* / “retrying prompt” style messages).

If you drop:

  • openclaw --version
  • which model/provider you’re using
tardy valley
#

@bold phoenix my agent said this in response:

okay, the investigation found something concrete. it's not any of the 4 causes from the discord response — it's actually a pattern specific to our setup.

what's happening: we have contextPruning.mode: "cache-ttl" enabled. after the first compaction fires (at ~180k tokens, which is correct given our 200k context + 20k reserve), openclaw inserts an openclaw.cache-ttl pruning entry. that entry then causes a second compaction to fire on the very next turn — but at only ~2-4k tokens. so it's compacting an already-compacted context, which is the "lobotomy" feeling.

there's direct evidence in the session logs:

compaction  →  tokensBefore=182026
cache-ttl   →  (inserted immediately after)
compaction  →  tokensBefore=2388   ← this shouldn't happen

this pattern repeats multiple times. the compaction guard that should say "we just compacted, don't do it again" isn't accounting for the cache-ttl entry that gets wedged in between.

likely fix: this is probably an upstream bug — the compaction guard should ignore openclaw.cache-ttl entries when deciding whether a recent compaction already happened.

workarounds we could try:

  1. disable cache-ttl pruning (contextPruning.mode → something else) — tradeoff is higher token usage

  2. lower reserveTokensFloor from 20k to ~10-15k — compaction triggers less often but doesn't fix the root cause

bold phoenixBOT
#

Yep — what your agent found is a real, known bug, not just “normal compaction retry” behavior.

Specifically: when contextPruning.mode: "cache-ttl" is enabled, OpenClaw used to append a custom session entry openclaw.cache-ttl in between a compaction and the next prompt. The compaction guard in the embedded agent path only checked “is the last entry a compaction?”, so the trailing custom entry made it miss the fact that you just compacted → immediate second compaction at tiny token counts (the “lobotomy” compaction).

This is tracked here:

What to do

  1. Check your version: openclaw --version
  • The fix is included in v2026.2.12 (and later). If you’re older than that, upgrading should stop this specific “2–4k tokens” second-compaction pattern.
  1. If you can’t upgrade right now, workaround is exactly what you listed:
{
agents: {