Summary

The active-memory plugin times out on every turn (even with timeoutMs: 30000), which cascades into dreaming's deep phase never promoting any candidates. All 716 recall entries have recallCount: 0, signalCount: 1, and maxScore: 0.58 — all below the deep gates (minRecallCount: 3, minScore: 0.8).

I believe this is the root cause of the silent dreaming failure, and it's a chain reaction:

active-memory times out
  → memory search never completes
  → recallCount stays at 0
  → signalCount (recallCount + dailyCount + groundedCount) = 1
  → below minRecallCount: 3
  → 0 candidates ranked → 0 promoted

Environment

• OpenClaw: 2026.5.16-beta.2 (also reproduced on beta.3)
• Agent: xue (single agent, direct chat only)
• Chat model: xiaomi-coding/mimo-v2.5 (MiMo reasoning model)
• Embedding: nvidia/llama-nemotron-embed-1b-v2 via integrate.api.nvidia.com/v1
• Embedding latency: ~1.9s (healthy, tested independently)
• OS: Windows 10 (x64)

active-memory timeout behavior

Log output

04:22:32 [plugins] active-memory: agent=xue ... activeProvider=xiaomi-coding activeModel=mimo-v2.5 start timeoutMs=10000
04:27:24 [plugins] [hooks] before_prompt_build handler from active-memory failed: timed out after 10000ms

What I've tried

Increasing timeoutMs has no effect — the plugin still times out.

Related issues

• active-memory recall subagent can deadlock on the main lane inside before_prompt_build #79026 — Lane deadlock: the recall subagent runs on the same main lane as the parent turn, causing it to wait behind the current turn → deadlock → timeout. This is likely our case.
• Feature: expose before_prompt_build modifying-hook timeout as config #74908 — Hardcoded 15s external hook timeout on before_prompt_build, independent of timeoutMs. This would explain why even timeoutMs: 30000 doesn't help.
• Active Memory with Cerebras gpt-oss-120b times out and can pin gateway CPU #73801 — Similar timeout/CPU issues with other slow providers.

Dreaming state

Memory status (openclaw memory status --deep)

Memory Search (xue)
Provider: openai (requested: openai)
Model: nvidia/llama-nemotron-embed-1b-v2
Indexed: 22/22 files · 203 chunks
Vector store: unknown
Vector dims: 2048
FTS: ready
Embedding cache: enabled (236 entries)
Recall store: 716 entries · 0 promoted · 714 concept-tagged
Dreaming: 0 3 * * * · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3

short-term-recall.json analysis

Total entries: 716
recallCount=0:   716/716  (all zero)
dailyCount=1:    716/716  (all 1)
groundedCount=0: 716/716  (all zero)
maxScore:        0.58     (all same)
signalCount:     1        (recallCount + dailyCount + groundedCount)
queryHashes:     1        (all same)

Every entry fails all three deep gates:

• signalCount (1) < minRecallCount (3) ❌
• maxScore (0.58) < minScore (0.8) ❌
• queryHashes (1) < minUniqueQueries (3) ❌

Deep sleep output (every night)

# Deep Sleep
- Repaired recall artifacts: rewrote recall store.
- Ranked 0 candidate(s) for durable promotion.
- Promoted 0 candidate(s) into MEMORY.md.

Questions

1. Is active-memory recall subagent can deadlock on the main lane inside before_prompt_build #79026 (lane deadlock) the root cause of our timeout? The MiMo reasoning model is slow, and the recall subagent might be deadlocking on the main lane.

2. Is Feature: expose before_prompt_build modifying-hook timeout as config #74908 (hardcoded 15s hook timeout) still present in beta.2/beta.3? If so, even increasing timeoutMs won't help.

3. Should we disable active-memory and rely on manual memory_search tool calls instead? The plugin seems unreliable with slow/reasoning models.

4. Is there a recommended provider/model for active-memory recall that avoids these issues? We have DeepSeek V4 Pro and GPT-5.5 available as alternatives to MiMo.

Workaround tried

• Increased timeoutMs to 30000 — no effect
• Verified NVIDIA embedding API is healthy (~1.9s) — not the bottleneck
• The issue is in the plugin's execution path, not the embedding provider

Impact

• Dreaming deep phase has never promoted anything across multiple weeks
• 716 recall entries all stuck at recallCount: 0
• The memory system appears to be running but is silently failing to consolidate