Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

agents.defaults.compaction.model config value is ignored at runtime; compaction uses the session's current model instead of the explicitly configured override.

Steps to reproduce

1. Install OpenClaw 2026.5.7 on macOS with session primary model specified (ex: nvidia/z-ai/glm-5.1) and fallback chain (ex: nvidia/deepseek-ai/deepseek-v4-pro, nvidia/moonshotai/kimi-k2.6, nvidia/nemotron-3-super-120b-a12b, minimax-portal/MiniMax-M2.7, ollama/qwen3.5:9b).
2. Set agents.defaults.compaction.model to a specific model (ex: minimax-portal/MiniMax-M2.7) in openclaw.json.
3. Observe hot-reload detection in gateway.log: [reload] config change detected; evaluating reload (agents.defaults.compaction.model).
4. Restart gateway to ensure fresh session cache picks up config change.
5. Trigger a compaction event (allow session context to exceed threshold).
6. Check gateway.log for auto-compaction succeeded for <model> line.

Expected behavior

Compaction should use the model specified in agents.defaults.compaction.modelof openclaw.json(ex: minimax-portal/MiniMax-M2.7). Per docs at docs/gateway/configuration-reference.md, this key should override the model used for compaction independently of the session fallback chain.

Actual behavior

Every compaction event uses the session's current active model (from the fallback chain), not the explicitly configured compaction.model value. Evidence:

• Config set to: minimax-portal/MiniMax-M2.7 (verified in openclaw.json)
• Hot-reload detected: 2026-05-10T12:10:35.760-05:00 [reload] config change detected; evaluating reload (agents.defaults.compaction.model)
• Gateway restarted: 2026-05-10T17:00:51.558-05:00 (SIGTERM), 2026-05-10T17:00:55.708-05:00 (health-monitor started)
• Compaction at 16:23 (before restart): auto-compaction succeeded for nvidia/deepseek-ai/deepseek-v4-pro
• Compaction at 19:04, 19:09 (after restart): logs show [compaction] rotated active transcript without naming model; compaction-diag entries continue to show provider=nvidia/deepseek-ai/deepseek-v4-pro
• Historical pattern: When session primary was Minimax (April 18-28), compaction used Minimax. When session primary shifted to NVIDIA models (May 7+), compaction followed the session model — never the compaction.model config value.

This suggests the runtime code path for compaction reads the session's current model, not the compaction.model config key.

OpenClaw version

2026.5.7

Operating system

macOS 15.4 (Apple Silicon, arm64)

Install method

npm global (/opt/homebrew/lib/node_modules/openclaw)

Model

nvidia/z-ai/glm-5.1 (session primary); minimax-portal/MiniMax-M2.7 (intended compaction model)

Provider / routing chain

Fallback chain: nvidia/deepseek-ai/deepseek-v4-pro -> nvidia/moonshotai/kimi-k2.6 -> nvidia/nemotron-3-super-120b-a12b -> minimax-portal/MiniMax-M2.7 -> ollama/qwen3.5:9b Compaction intended: openclaw -> minimax-portal (direct) -> MiniMax-M2.7

Additional provider/model setup details

In the bug report above, the examples used describe the following configuration:

• minimax-portal/MiniMax-M2.7 is a paid model (not on NVIDIA free tier), which is why we want compaction to use it instead of the NVIDIA free-tier models that hit rate limits during use, which frequently triggers fallback model selection, which frequently triggers compaction.
• The config key agents.defaults.compaction.model only accepts a string (not an object with fallbacks), which is consistent with the schema but means there's no fallback if the configured model is unavailable.
• Config hot-reload correctly detects changes to compaction.model but the change does not propagate to the compaction runtime.

Logs, screenshots, and evidence

# Config (openclaw.json) — compaction.model explicitly set
"compaction": {
  "mode": "safeguard",
  "reserveTokensFloor": 100000,
  "memoryFlush": { "enabled": true, "softThresholdTokens": 160000 },
  "model": "minimax-portal/MiniMax-M2.7",
  "notifyUser": true,
  "truncateAfterCompaction": true
}

# Hot-reload detection
2026-05-10T09:18:17.870-05:00 [reload] config change detected; evaluating reload (agents.defaults.compaction.model)
2026-05-10T12:10:35.760-05:00 [reload] config change detected; evaluating reload (agents.defaults.compaction.model)

# Gateway restart
2026-05-10T17:00:51.558-05:00 SIGTERM received
2026-05-10T17:00:55.708-05:00 health-monitor started

# Compaction BEFORE config change — uses session model (expected for pre-change)
2026-05-10T16:23:11.788-05:00 [agent/embedded] auto-compaction succeeded for nvidia/deepseek-ai/deepseek-v4-pro; retrying prompt

# Compaction AFTER restart — still uses session model, not configured compaction.model
2026-05-10T19:04:39.040-05:00 [agent/embedded] [compaction] rotated active transcript after compaction
2026-05-10T19:09:46.594-05:00 [agent/embedded] [compaction] rotated active transcript after compaction
# (model not logged in these rotation lines; but compaction-diag in err.log continues to show deepseek-v4-pro as provider)

# Historical evidence — compaction model tracks session model, not config:
# April 18-28 (session primary = minimax): compaction used minimax-portal/MiniMax-M2.7
# May 7+ (session primary = nvidia glm-5.1): compaction used nvidia/z-ai/glm-5.1 or nvidia/deepseek-ai/deepseek-v4-pro
# Never observed: compaction using a model different from the session's current primary/fallback

# Compaction-diag entries all show session model, never the config override
2026-05-10T11:36:13.949-05:00 [compaction-diag] ... provider=nvidia/deepseek-ai/deepseek-v4-pro ... outcome=failed
2026-05-10T12:54:38.937-05:00 [compaction-diag] ... provider=nvidia/deepseek-ai/deepseek-v4-pro ... outcome=failed
2026-05-10T16:14:06.112-05:00 context overflow detected; attempting auto-compaction for nvidia/deepseek-ai/deepseek-v4-pro

Impact and severity

• Affected: All users who set agents.defaults.compaction.model to a model different from their session primary/fallback chain
• Severity: Blocks workflow — compaction hits NVIDIA free-tier rate limits (429 errors observed), causing compaction to fail or timeout, which triggers the vicious cycle of repeated compaction attempts on an already degraded session
• Frequency: Always — every compaction event ignores the configured model
• Consequence: Users pay for a dedicated compaction model (Minimax M2.7) to avoid rate limits, but the config is a no-op. The compaction continues hitting the free-tier model, timing out, and degrading session quality. No workaround exists within the config system.

Additional information

• Also filed as observation in issue [Feature]: Pre-reset agentic memory flush — /new and daily reset should get the same memory flush as compaction #45608 (pre-reset agentic memory flush), though that issue covers a different symptom of compaction degradation.
• The compaction.model config key exists and is documented, hot-reload detects changes to it, but the runtime code path for compaction does not appear to read it. This makes it a "config theater" bug — the setting appears to work but has no effect.
• No known workaround: even a full gateway restart does not cause compaction to use the configured model.
• Last known good: NOT_ENOUGH_INFO — we only started explicitly setting compaction.model on 2026-05-10, and historical data suggests compaction always tracked the session model.