openclaw - 💡(How to fix) Fix Active Memory embedded run times out despite configured fast recall model [2 comments, 3 participants]

Summary

Active Memory is enabled and triggers for eligible Feishu direct-message sessions, but the blocking memory sub-agent consistently times out and returns no memory summary (summaryChars=0).

This happens both when Active Memory inherits the current chat model and after explicitly configuring a dedicated recall model.

Environment

• OpenClaw: 2026.4.25 (aa36ee6 shown by CLI)
• Runtime: Node v22.22.0
• OS: macOS / Darwin 21.6.0 x64
• Channel: Feishu direct messages
• Gateway service: LaunchAgent, loopback gateway
• Active Memory plugin: enabled

Active Memory config

{
  "plugins": {
    "entries": {
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main", "nia", "elon", "henry", "muse"],
          "allowedChatTypes": ["direct"],
          "model": "qwen-portal/qwen3.6-plus",
          "queryMode": "recent",
          "promptStyle": "balanced",
          "timeoutMs": 15000,
          "maxSummaryChars": 220,
          "persistTranscripts": false,
          "logging": true
        }
      }
    }
  }
}

The configured model is present in the qwen-portal provider model list. After a Gateway restart, logs confirm that Active Memory is using the configured model.

What happened

Before setting an explicit Active Memory model, it inherited the chat model and timed out:

active-memory: agent=elon session=agent:elon:feishu:direct:<redacted> activeProvider=openai-codex activeModel=gpt-5.5 start timeoutMs=15000 queryChars=1882
active-memory: agent=elon session=agent:elon:feishu:direct:<redacted> activeProvider=openai-codex activeModel=gpt-5.5 done status=timeout elapsedMs=33457 summaryChars=0

After setting plugins.entries.active-memory.config.model = "qwen-portal/qwen3.6-plus" and restarting Gateway, the model switch did take effect, but runs still time out:

active-memory: agent=elon session=agent:elon:feishu:direct:<redacted> activeProvider=qwen-portal activeModel=qwen3.6-plus start timeoutMs=15000 queryChars=1329
active-memory: agent=elon session=agent:elon:feishu:direct:<redacted> activeProvider=qwen-portal activeModel=qwen3.6-plus done status=timeout elapsedMs=71207 summaryChars=0

active-memory: agent=main session=agent:main:feishu:direct:<redacted> activeProvider=qwen-portal activeModel=qwen3.6-plus start timeoutMs=15000 queryChars=698
active-memory: agent=main session=agent:main:feishu:direct:<redacted> activeProvider=qwen-portal activeModel=qwen3.6-plus done status=timeout elapsedMs=67063 summaryChars=0

active-memory: agent=elon session=agent:elon:feishu:direct:<redacted> activeProvider=qwen-portal activeModel=qwen3.6-plus start timeoutMs=15000 queryChars=1224
active-memory: agent=elon session=agent:elon:feishu:direct:<redacted> activeProvider=qwen-portal activeModel=qwen3.6-plus done status=timeout elapsedMs=74266 summaryChars=0

Expected behavior

• Active Memory should either complete within the configured timeoutMs budget and inject a compact memory summary, or skip cleanly within that budget.
• The user-visible reply path should not be delayed far beyond timeoutMs.

Actual behavior

• Active Memory consistently logs status=timeout and summaryChars=0.
• The elapsed time reported in logs is far above the configured timeoutMs=15000 (for example ~67s to ~74s after the model switch).
• No memory summary is injected.

Additional check

The underlying memory search itself appears healthy: direct memory_search calls return relevant results in roughly a couple of seconds. So this looks more like an Active Memory embedded-run / timeout enforcement / model invocation issue than a memory-index availability issue.

Questions

1. Should the Active Memory embedded run be force-aborted at timeoutMs, or is the larger elapsedMs expected because the provider request continues in the background?
2. Is there a recommended low-latency model profile or config for Active Memory recall?
3. Would it make sense for Active Memory to fail open faster when the embedded run exceeds the configured timeout, so the main reply path is not delayed?