Dreaming times out

[inland orbit]

Here is the log https://cl1p.net/4568

[analog bear]

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

[eager quest]

I can read the log. The key lines are:

memory-core: narrative generation ended with status=timeout
stalled session ... sessionKey=agent:sql:dreaming-narrative-... activeWorkKind=model_call

That points to the Dream Diary narrative subagent timing out while waiting on the model call. In current source this diary generation is best-effort and has a 60s wait; it should not by itself mean the core memory promotion succeeded or failed. It mainly means the background “write a readable dream diary entry” turn is hanging/too slow.

First, what version are you on?

openclaw --version

Then please grab these, ideally from right after another timeout:

[eager quest]

openclaw status --all
openclaw models status
openclaw logs --follow

Likely fixes/workarounds:

• If you’re on an older build, update first and restart the gateway.
• Check whether the default runtime model/provider is slow, overloaded, auth-broken, or local-model stalled. The dreaming diary uses the default runtime model.
• If you just want the timeout spam gone while debugging, disable dreaming or reduce its frequency in plugins.entries.memory-core.config.dreaming, then restart the gateway. Config changes require restart.

Docs:
https://docs.openclaw.ai/concepts/dreaming
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting

[inland orbit]

I've always had this issue, I'm on the latest 2025.5.22 version and tried to report the 60s timeout as an issue but was removed as 'not going to implement'

[eager quest]

Yeah, that tracks with the current implementation. I checked source/docs: the Dream Diary narrative wait is hardcoded at 60s, and I don’t see a supported config key to change only that timeout or disable only the diary writer.

Important distinction: this timeout is in the best-effort diary narrative path, not the durable memory promotion path. So it is noisy and annoying, but it should not mean dreaming as a whole failed.

Practical options right now:

• Leave it alone if memory promotion is working and you can tolerate the log noise.
• Make dreaming run less often with plugins.entries.memory-core.config.dreaming.frequency.
• Disable dreaming entirely if the Dreams UI/diary isn’t useful to you:

{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {

[eager quest]

            enabled: false
          }
        }
      }
    }
  }
}

Then restart the gateway after changing config.

Docs: https://docs.openclaw.ai/concepts/dreaming and https://docs.openclaw.ai/reference/memory-config

Also, just checking: did you mean 2026.5.22 rather than 2025.5.22?

[inland orbit]

I definately don't want to disable dreaming, can I at least stop it firing off four simulataneous prompts, which doesn't help

[eager quest]

You probably can reduce this without disabling dreaming.

Two things from source:

1. A single sweep is supposed to run sequentially: light -> REM -> deep. It awaits each phase, so “four simultaneous prompts” is not the intended shape inside one sweep.
2. Your log shows full sets repeating around 12:03, 12:04, 12:05. That looks like the dreaming cron is firing too often, so timed-out narrative runs are stacking before the old model calls fully settle.

First check:

openclaw memory status

or:

[eager quest]

/dreaming status

Look at the sweep cadence. If it’s every minute or very frequent, set it back to something sane, e.g. daily:

{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "0 3 * * *"
          }

[eager quest]

        }
      }
    }
  }
}

Then restart the gateway.

There is also a lower-level current config schema for phase enablement, but docs call phase policy internal, so I’d treat this as a workaround rather than a stable public API. If you want to keep deep promotion but stop light/REM diary prompts, current builds appear to accept:

{
  plugins: {
    entries: {

[eager quest]

      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "0 3 * * *",
            phases: {
              light: { enabled: false },
              rem: { enabled: false },
              deep: { enabled: true }
            }
          }
        }
      }
    }
  }

[eager quest]

}

That should reduce it to the deep phase path only, but it may change the quality of promotion signals because light/REM feed reinforcement into deep. I’d fix the cadence first.

[inland orbit]

dreaming frequency makes no difference, this happens every time it dreams. If I limit the model to only prompt 1 at a time will that help?

[eager quest]

Yes, it can help if the failures are from provider/local-backend concurrency pressure. It will not help if each individual diary prompt takes more than 60s even when it is the only request.

I don’t see a per-model “only one request at a time” knob. The closest supported knobs are the OpenClaw run queues:

{
  agents: {
    defaults: {
      maxConcurrent: 1,
      subagents: {
        maxConcurrent: 1
      }
    }
  }
}

[eager quest]

Then restart the gateway.

What this does:

• agents.defaults.maxConcurrent: 1 serializes main agent runs across sessions.
• agents.defaults.subagents.maxConcurrent: 1 serializes native subagent lane runs.
• It reduces simultaneous model pressure, but it also slows normal OpenClaw responsiveness because unrelated sessions/background work may wait.

Before changing it, you can check current values:

openclaw config get agents.defaults.maxConcurrent
openclaw config get agents.defaults.subagents.maxConcurrent

If this still times out with both set to 1, the issue is not concurrency; it’s that the Dream Diary narrative call itself is too slow/stuck for the hardcoded 60s wait. In that case the cleaner workaround is still phase tuning, or using a faster/more reliable default model for the runtime that dreaming uses.

[inland orbit]

Why can't they just expose a parameter?

[eager quest]

They could. I can’t speak for maintainers, but the likely reason is that exposing “just one timeout” turns into a bigger contract pretty quickly:

• timeout for diary generation vs phase work vs cleanup wait
• what happens to orphaned/stalled narrative sessions
• whether longer waits block later phases or heartbeats
• whether local models should get different defaults than cloud models
• whether the real fix should be “make diary optional/queued” instead of “wait longer”

My take: the better product knob is probably not “60s -> configurable”, but something like:

dreaming: {
  narrative: {
    enabled: true,
    timeoutSeconds: 180,
    maxConcurrent: 1

[eager quest]

  }
}

That would address your case without making the durable memory phases depend on a slow diary writer.

Since this is feature/request territory, the right path is still a GitHub issue with the exact behavior and logs: https://github.com/openclaw/openclaw/issues

I’d frame it as “Dream Diary narrative needs separate config for timeout/concurrency or disablement, while keeping dreaming enabled.” That’s more actionable than only asking to raise the hardcoded 60s.

[inland orbit]

I've reported it again