#Does openclaw do auto compaction

1 messages · Page 1 of 1 (latest)

solar karma
#

If yes how can I let it trigger way earlier

spiral widgetBOT
#

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

jagged martenBOT
#

Yep — OpenClaw has auto-compaction (and you can also force it manually with /compact).

Auto-compaction (Pi runtime) happens when either:

  • the model throws a context overflow → compact → retry, or
  • after a successful turn when contextTokens > contextWindow - reserveTokens

So to make it trigger earlier, you generally want a bigger reserveTokens (that makes the threshold hit sooner).

Easiest: force it anytime

In the chat:

/compact Focus on decisions + current TODOs

Make auto-compaction trigger earlier (config)

In ~/.openclaw/openclaw.json:

# 
{
  agents: {
    defaults: {
      compaction: {
        // Bigger = compacts earlier
        reserveTokens: 40000,

        // Optional: how much recent context to keep after compaction
        keepRecentTokens: 12000
      }
    }
  }
}

Then restart the Gateway.

solar karma
#

even if the model suport 200k i barely want to do that. i think 50k is sweet point for what we are doing here. i use mostly custom provider, in this case i think 200k is the default context weindow so i will set a 150k reserve tokens?

jagged martenBOT
#

If you’re on a custom provider and you didn’t specify contextWindow for the model, then yes: OpenClaw currently defaults it to 200000 for custom providers. (Docs: https://docs.openclaw.ai/concepts/model-providers)

And your math is right:

  • auto-compaction threshold is roughly: contextWindow - reserveTokens
  • so with contextWindow = 200k and you want compaction to kick in around ~50k,
    set reserveTokens ≈ 150k.

Recommended config

Also make sure keepRecentTokens is below that threshold, otherwise you can end up “compacting” but still staying above the trigger point.

{
  agents: {
    defaults: {
      compaction: {
# 
        reserveTokens: 150000,   // triggers around 50k (if contextWindow is 200k)
        keepRecentTokens: 20000  // keep last ~20k verbatim; summarize older stuff
      }
    }
  }
}

Two gotchas

  1. Compaction cost/frequency: doing this will make compaction happen much more often. That can save you per-turn context costs, but you’ll pay extra “summary turns”. It’s worth it when your normal turns would otherwise drag huge context every time.

  2. Make contextWindow explicit (best practice): if your proxy/model isn’t actually 200k, set it in models.providers.<yourProvider>.models[] so OpenClaw’s token math matches reality.

Deep dive on the trigger logic: https://docs.openclaw.ai/reference/session-management-compaction

If you paste your models.providers.<name>.models entry (just that block), I can suggest a couple of “safe” presets for a ~50k operating point.

unkempt hedge
#

Adding to what Krill said — another approach that works well if you want proactive compaction without touching config: have your agent monitor its own context usage during heartbeats.

You can call session_status which shows something like 45000/200000 tokens. Then in your HEARTBEAT.md, add a rule like:

If context usage >65%, proactively compact.

The agent will check context during each heartbeat cycle and trigger /compact before it ever hits the auto-compaction threshold. This gives you softer, more predictable compaction without risking it firing every turn from an aggressive reserveTokens setting.

Both approaches work — config-based for a hard threshold, heartbeat-based for a more dynamic "compact when I'm getting full" pattern.

jagged martenBOT
#

Good idea in spirit, but small correction on what’s actually possible today:

  • session_status is an OpenClaw operator tool (what we can call here / what /status shows you in chat). The LLM running your heartbeat doesn’t have a “read my current contextTokens” tool it can call.
  • And /compact is a control command on inbound chat messages — it isn’t something the agent can “invoke internally” during a heartbeat run unless it literally receives /compact as an incoming message from an allowed sender.

So if you want “compact around ~50k”, the supported / predictable way is still the config knob:

reserveTokens ≈ contextWindow - 50k (and keep keepRecentTokens comfortably below 50k so compaction doesn’t immediately re-trigger).

If you’d like “compact at X%” as a first-class feature, that’d be a solid GitHub issue/feature request.