openclaw 4.10 on VPS - slow startup and response issues | Friends of the Crustacean 🦞🤝 | Page 1

crisp coyote Apr 13, 2026, 3:38 PM

#

overnight my openclaw has started responding very slowly, and in discord it often gets hung on a response and only gives me emoji reacts, and I can see sessions in the terminal are not loading my inputs from the discord chat. I noticed there are many sessions from the dreaming function. I suspect my sessions and context are clogged. how do I pinpoint the issue and resolve

marble mothBOT Apr 13, 2026, 3:38 PM

#

glass tigerBOT Apr 13, 2026, 3:38 PM

#

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

marble mothBOT Apr 13, 2026, 3:38 PM

#

ripe nacelleBOT Apr 13, 2026, 3:40 PM

#

Let me check the local docs and repo layout first, then I’ll give you the shortest path to isolate it.

#

That does sound like either session-state backlog, a stuck channel/runtime path, or a dreaming/cron lane piling up and starving normal turns.

First, please paste:

openclaw --version

Then run this exact triage ladder on the gateway host:

openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw cron status
openclaw cron list

#

openclaw sessions --all-agents --json
openclaw sessions cleanup --all-agents --dry-run --json
openclaw logs --follow

Then, while openclaw logs --follow is running, send one Discord message that usually hangs.

What I’d look for in the logs:

mention required, blocked, allowlist, pairing request
model/auth/rate limit errors
timeout waiting for session store lock
lots of cron/dreaming activity right when Discord input arrives
requests-in-flight or anything showing the main lane is busy

A few important bits:

#

Many dreaming sessions are not automatically bad. Dreaming uses one managed cron sweep in the background.
What is suspicious is if those isolated cron/dream sessions are not being pruned. Default cron.sessionRetention is 24h, so if they are piling up for days, that’s a clue.
If one Discord thread got stale/corrupted, a quick fix is to send:

/new

or

/reset

in that thread. For oversized context, try:

#

/compact

Fastest safe mitigation test:

Turn dreaming off temporarily:
```
/dreaming off
```
or disable plugins.entries.memory-core.config.dreaming.enabled
Restart gateway:
```
openclaw gateway restart
```
Retry Discord
If sessions cleanup --dry-run shows lots of stale entries, run:

#

   openclaw sessions cleanup --all-agents --enforce

Docs:

If you paste the outputs from the commands above, I can help narrow it down pretty quickly.

crisp coyote Apr 13, 2026, 3:41 PM

#

🦞 OpenClaw 2026.4.10 (44e5b62) — No $999 stand required.

15:41:32+00:00 [sessions] capped session entry count
15:41:32+00:00 [sessions] rotated session store file
Agent: nox
Session store: /home/openclaw/.openclaw/agents/nox/sessions/sessions.json
Applied maintenance. Current entries: 500

Agent: malakor
Session store: /home/openclaw/.openclaw/agents/malakor/sessions/sessions.json
Applied maintenance. Current entries: 14

Agent: forge
Session store: /home/openclaw/.openclaw/agents/forge/sessions/sessions.json
Applied maintenance. Current entries: 6

Agent: spot
Session store: /home/openclaw/.openclaw/agents/spot/sessions/sessions.json
Applied maintenance. Current entries: 1

Agent: magnus
Session store: /home/openclaw/.openclaw/agents/magnus/sessions/sessions.json
Applied maintenance. Current entries: 4

Agent: lyra
Session store: /home/openclaw/.openclaw/agents/lyra/sessions/sessions.json
Applied maintenance. Current entries: 16

ripe nacelleBOT Apr 13, 2026, 3:42 PM

#

Yep, this confirms real session-store pressure.

What your output means:

Current entries: 500 on nox = it hit the default session.maintenance.maxEntries cap
rotated session store file = sessions.json got big enough to rotate
so, yes, that agent’s session store was busy enough to need maintenance

That does not prove dreaming is the only cause, but it does prove the store is churning.

Next 3 checks I’d do:

openclaw sessions --agent nox --active 240
openclaw cron list
openclaw logs --follow

#

Then send one Discord message that usually hangs, and watch for:

timeout waiting for session store lock
requests-in-flight
mention required
blocked / allowlist
rate limit / auth / model errors

A likely path here is:

dreaming/cron created lots of isolated sessions
nox hit the cap
Discord turns are now competing with maintenance / session churn / a stale big thread

Fastest isolation test:

turn dreaming off temporarily

#

   /dreaming off

restart gateway
```
openclaw gateway restart
```
retry Discord

If that immediately improves things, you found the hot path.

Also, for the stuck Discord thread itself, do:

/new

#

If it is just oversized rather than corrupted:

/compact

What I’d check in config after that:

{
  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "7d",
    },
  },

#

  cron: {
    sessionRetention: "24h", // make sure this is not false
  },
}

If you want, paste the output of:

openclaw sessions --agent nox --active 240
openclaw cron list

and I can tell you pretty quickly whether dreaming is the culprit or just the thing that exposed another issue.

Docs:

#

crisp coyote Apr 13, 2026, 3:47 PM

#

The output is too big to paste

openclaw@defind-openclaw:~$ openclaw sessions --agent nox --active 240
openclaw cron list
openclaw logs --follow

🦞 OpenClaw 2026.4.10 (44e5b62) — Greetings, Professor Falken

Session store: /home/openclaw/.openclaw/agents/nox/sessions/sessions.json
Sessions listed: 110
Filtered to last 240 minute(s)
Kind Key Age Model Tokens (ctx %) Flags
group agent:nox:discor...143518 7m ago google/gemini-3-flash-preview 55k/200k (27%) system id:e93d4f77-8f67-4019-8c95-f1b99f618de7
direct agent:nox:dreami...852572 18m ago google/gemini-3-flash-preview 18k/200k (9%) id:40ee84fd-ddeb-48f3-8b96-f3d52c561646
direct agent:nox:dreami...852572 19m ago google/gemini-3-flash-preview 19k/200k (9%) id:5fcd3ea1-eaa2-42bb-9f5e-9329b52b84b9
direct agent:nox:dreami...654477 20m ago google/gemini-3-flash-preview 18k/200k (9%) id:d6980439-0106-4dbb-bf61-25de6e5e7064
direct agent:nox:dreami...654477 21m ago google/gemini-3-flash-preview 18k/200k (9%) id:eeac61d7-81da-43ff-b2d8-c42b036f65c3

🦞 OpenClaw 2026.4.10 (44e5b62)
iMessage green bubble energy, but for everyone.

│
◇
ID Name Schedule Next Last Status Target Agent ID Model
5bc2ecf5-584f-4d13-98e7-ca06d2e3df1f Daily System Backup t... cron 0 0 * * * * @ UTC (stagg... in 19m 41m ago ok isolated main -
c1fef685-4094-4e2e-8937-1acfe760cb47 Memory Dreaming Promo... cron 0 3 * * * (exact) in 11h 13h ago ok main - -
e13e9639-030b-4434-ade9-9ba2ab555514 DeFind Daily Pulse Sy... cron 0 8 * * * @ UTC (exact) in 16h 8h ago ok isolated main openrouter/google...
dccca789-f505-4650-9749-014f52d593b0 admin:gws-skill-sync cron 0 2 * * 0 @ UTC (exact) in 5d 2d ago ok isolated main -

Schedule Next Last Status Target Agent ID Model
15:44:37+00:00 info 5bc2ecf5-584f-4d13-98e7-ca06d2e3df1f Daily System Backup t... cron 0 0 * * * * @ UTC (stagg... in 19m 41m ago ok isolated main -
15:44:37+00:00 info c1fef685-4094-4e2e-8937-1acfe760cb47 Memory Dreaming Promo... cron 0 3 * * * (exact) in 11h 13h ago ok main - -
15:44:37+00:00 info e13e9639-030b-4434-ade9-9ba2ab555514 DeFind Daily Pulse Sy... cron 0 8 * * * @ UTC (exact) in 16h 8h ago ok isolated main openrouter/google...
15:44:37+00:00 info dccca789-f505-4650-9749-014f52d593b0 admin:gws-skill-sync cron 0 2 * * 0 @ UTC (exact) in 5d 2d ago ok isolated main -
15:44:43+00:00 warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 24833 chars (limit 20000); truncating in injected context (sessionKey=agent:…518)
15:44:45+00:00 info plugins {"subsystem":"plugins"} active-memory: agent=nox session=agent:nox:discord:channel:1477528363278143518 start timeoutMs=15000 queryChars=1573
Log tail truncated (increase --max-bytes).
15:44:47+00:00 warn {"scope":"event-queue","level":"warn","type":"slow-listener","listener":"DiscordReactionRemoveListener","eventType":"MESSAGE_REACTION_REMOVE","durationMs":1132,"lane":"standard"}
15:44:51+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1727ms conn=13b0ed77…cada id=992acebe…c5fe
15:44:53+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1133ms conn=13b0ed77…cada id=5ebcb6eb…f485
15:44:53+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-03-14.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.

ripe nacelleBOT Apr 13, 2026, 3:48 PM

#

This is actually pretty revealing.

My read:

The scheduled dreaming job is probably not the thing blocking replies right now
- your dreaming cron says last run 13h ago, next in 11h
- so it is not actively hammering the system at this moment
Your Discord thread is not hitting raw context-window exhaustion
- 55k/200k (27%) is not terrible by itself
The clearest red flag is this
- workspace bootstrap file MEMORY.md is 24833 chars (limit 20000); truncating in injected context

That means MEMORY.md has gotten large enough that it is being truncated on turns. If this slowdown started “overnight”, dreaming/memory promotion may have bloated MEMORY.md, which then slows prompt assembly and can hurt behavior.

So my current hypothesis is:

#

dreaming may be the indirect cause
the direct pain is oversized bootstrap memory plus the active-memory path on each Discord turn

You also have a couple secondary signals:

active-memory ... start timeoutMs=15000
sessions.list 1727ms
slow-listener ... DiscordReactionRemoveListener
sqlite-vec unavailable, so recall is degraded

Those matter, but MEMORY.md is the loudest clue.

What I’d do next, in order

1. Reset the bad Discord thread

In that stuck thread:

#

/new

2. Turn dreaming off temporarily

/dreaming off

Then:

openclaw gateway restart

3. Trim `MEMORY.md`

Keep only durable, high-signal facts. Remove diary-ish stuff, repeated notes, and long narrative entries.

#

I’d try to get it well under 20k chars, ideally more like 10k to 15k.

4. Reproduce once with a bigger log tail

openclaw logs --follow --max-bytes 200000

Then send one Discord message and watch from:

active-memory start
to either:
assistant reply success
channel send failure
timeout/error

Config hardening I’d consider after cleanup

#

{
  agents: {
    defaults: {
      contextInjection: "continuation-skip",
    },
  },
  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "7d",
    },
  },
  cron: {
    sessionRetention: "24h",
  },

#

contextInjection: "continuation-skip" can reduce repeated bootstrap cost on safe continuation turns.

Short version

I don’t think “too many dreaming sessions” is the main live blocker.

I do think dreaming may have swollen MEMORY.md, and that oversized bootstrap memory is now dragging Discord turns.

Docs:

#

If you want, paste just:

the size of MEMORY.md
20 to 30 log lines after active-memory start

and I can help confirm whether the next bottleneck is memory lookup, model latency, or Discord delivery.

crisp coyote Apr 13, 2026, 3:52 PM

#

15:51:29+00:00 info discord-auto-reply {"module":"discord-auto-reply"} {"channelId":"1477528363278143518","reason":"no-mention"} discord: skipping guild message
15:51:31+00:00 warn {"scope":"event-queue","level":"warn","type":"slow-listener","listener":"DiscordReactionListener","eventType":"MESSAGE_REACTION_ADD","durationMs":1176,"lane":"standard"}
15:51:37+00:00 warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 24833 chars (limit 20000); truncating in injected context (sessionKey=agent:…518)
15:51:38+00:00 info plugins {"subsystem":"plugins"} active-memory: agent=nox session=agent:nox:discord:channel:1477528363278143518 start timeoutMs=15000 queryChars=1725
15:51:41+00:00 warn {"scope":"event-queue","level":"warn","type":"slow-listener","listener":"DiscordReactionListener","eventType":"MESSAGE_REACTION_ADD","durationMs":1328,"lane":"standard"}
15:51:42+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1042ms conn=13b0ed77…cada id=5557683b…2124
15:51:42+00:00 warn {"scope":"event-queue","level":"warn","type":"slow-listener","listener":"DiscordReactionRemoveListener","eventType":"MESSAGE_REACTION_REMOVE","durationMs":1171,"lane":"standard"}
15:51:46+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1126ms conn=13b0ed77…cada id=969a1751…0998
15:51:46+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-03-14.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:46+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-03-20.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:47+00:00 warn memory {"subsystem":"memory"} chunks written for MEMORY.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:49+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1452ms conn=13b0ed77…cada id=e9427d22…4140
15:51:49+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-04-11-discord-stuck.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:49+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-04-04.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:50+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-04-11.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:50+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2533ms conn=13b0ed77…cada id=8ef64dd9…ccf3
15:51:51+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-04-12.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:51+00:00 warn memory {"subsystem":"memory"} chunks written for memory/2026-04-13.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:51+00:00 warn memory {"subsystem":"memory"} chunks written for memory/spot-discovery-parameters.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
15:51:52+00:00 info plugins {"subsystem":"plugins"} active-memory: agent=nox session=agent:nox:discord:channel:1477528363278143518 done status=empty elapsedMs=13625 summaryChars=0
15:51:52+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 98ms conn=13b0ed77…cada id=1eb8b867…cf0c
15:51:56+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1139ms conn=13b0ed77…cada id=e5ec3ef6…bcaf
15:52:02+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 1980ms conn=13b0ed77…cada id=efb63a2c…4283
15:52:04+

ripe nacelleBOT Apr 13, 2026, 3:53 PM

#

Nice, this narrows it down a lot.

I think you have 3 separate issues, and the biggest one is not dreaming.

1. Some Discord messages are being skipped on purpose

This line is decisive:

reason":"no-mention"} discord: skipping guild message

So at least some messages are not entering the reply path at all because mention gating is on.

If you want replies without pinging the bot every time, set Discord requireMention: false for that guild/channel, or keep @mentioning it.

Docs: https://docs.openclaw.ai/channels/discord

#

2. Active memory is burning ~13.6s and returning nothing

This is your main latency clue:

active-memory ... start timeoutMs=15000
...
active-memory ... done status=empty elapsedMs=13625

That is a huge delay for a result of empty.

And you also have:

sqlite-vec unavailable

#

Vector recall degraded

So memory search is running in degraded mode, touching a bunch of files, then returning nothing.

3. `MEMORY.md` is oversized and being truncated every turn

workspace bootstrap file MEMORY.md is 24833 chars (limit 20000)

That is also bad. It means your bootstrap context has gotten fat enough to be truncated on injection.

So my updated diagnosis is:

not primarily “too many dreaming sessions”

#

more likely:
1. Discord mention gating drops some messages
2. active-memory is slow and mostly useless right now
3. MEMORY.md has become too large

What I would do right now

Fast isolate

In Discord:

/active-memory off --global
/dreaming off
/new

Then restart:

#

openclaw gateway restart

If replies become normal, the slowdown is in the memory path, not session clogging.

Clean up `MEMORY.md`

Trim it down hard. Keep only durable facts.
Get it well under 20k chars, ideally closer to 10k to 15k.

Verify memory subsystem

Run:

openclaw doctor
openclaw memory status --deep

#

If memory is degraded because sqlite-vec is unavailable, that is the next thing to repair.

My priority order

fix no-mention behavior
disable active-memory temporarily
trim MEMORY.md
restart gateway
then revisit dreaming if needed

So yeah, I think you were right that “context/memory” is involved, but the log points more at mention gating + slow active-memory + bloated MEMORY.md than at dream sessions themselves.

Docs:

#

If you want, send back just the output of:

openclaw memory status --deep

That should tell us whether the next fix is sqlite-vec, embeddings, or just turning active-memory off for good.

stark sand Apr 13, 2026, 3:54 PM

#

Same thing happening on telegram fyi @crisp coyote

ripe nacelleBOT Apr 13, 2026, 3:54 PM

#

That’s useful, thanks. It means the root problem is probably not Discord-specific.

So I’d update the diagnosis to:

Discord no-mention is a real side issue on Discord
but the cross-channel slowdown points more strongly to:
- active-memory taking ~13.6s
- MEMORY.md being oversized/truncated
- degraded memory recall because sqlite-vec is unavailable

If it’s happening on Telegram too, I’d test this globally first:

/active-memory off --global
/dreaming off

#

then:

openclaw gateway restart

If both Discord and Telegram improve right after that, you’ve basically confirmed the memory pipeline is the bottleneck.

So at this point my order would be:

/active-memory off --global
trim MEMORY.md
/dreaming off
openclaw gateway restart
openclaw memory status --deep

If Sherbok posts openclaw memory status --deep, that should tell us whether the next fix is memory indexing / sqlite-vec versus just leaving active-memory off.

#

Docs:

crisp coyote Apr 13, 2026, 4:08 PM

#

ok active memory seems to have been the issue, but this is a feature I still want, how can I set this up correctly without the latency issues

ripe nacelleBOT Apr 13, 2026, 4:10 PM

#

Yep, that tracks. If turning off active-memory fixed it, I’d keep the feature, but re-enable it in a much tighter configuration.

What I’d do

1. Fix the memory backend first

Run:

openclaw memory status --deep
openclaw doctor

You want to confirm:

which embedding provider active-memory is actually using
whether it is healthy
whether sqlite-vec is available

#

Right now your logs show sqlite-vec unavailable, which means OpenClaw is falling back to a slower path.

2. Make provider selection explicit

Do not leave memory search on auto-detect if you want predictable latency.

Start with an explicit memory search provider/model under agents.defaults.memorySearch, for example Gemini if that is what you already use:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "gemini",
        model: "gemini-embedding-001",
        sources: ["memory"],
      },

#

    },
  },
}

That avoids provider drift and keeps the corpus limited to memory files, not session transcripts.

3. Re-enable active-memory in a small, fast mode

I would start smaller than the docs default for your setup:

{
  plugins: {
    entries: {
      "active-memory": {

#

        enabled: true,
        config: {
          enabled: true,
          agents: ["nox"],
          allowedChatTypes: ["direct"],
          queryMode: "message",
          promptStyle: "balanced",
          timeoutMs: 4000,
          maxSummaryChars: 180,
          cacheTtlMs: 300000,
          logging: true,
        },
      },
    },
  },

#

Why this shape:

allowedChatTypes: ["direct"] keeps it out of noisy group/thread traffic first
queryMode: "message" is faster than recent
timeoutMs: 4000 stops 13 to 15 second stalls
maxSummaryChars: 180 keeps injected memory tiny
cacheTtlMs helps repeated similar turns

Once that is stable, you can relax it to queryMode: "recent" if you want richer recall.

4. Trim `MEMORY.md`

This matters separately from active-memory.

#

Your MEMORY.md is over the bootstrap limit, so every turn is carrying a truncated memory file. Keep it short and durable. I’d get it below 10k to 15k chars if possible.

5. Turn logging off after tuning

While testing:

/trace on
/verbose on

After it behaves, set logging: false again.

My recommended rollout

get memory status --deep healthy
trim MEMORY.md
enable active-memory for direct chats only

#openclaw 4.10 on VPS - slow startup and response issues

What I’d do next, in order

1. Reset the bad Discord thread

2. Turn dreaming off temporarily

3. Trim MEMORY.md

4. Reproduce once with a bigger log tail

Config hardening I’d consider after cleanup

Short version

1. Some Discord messages are being skipped on purpose

2. Active memory is burning ~13.6s and returning nothing

3. MEMORY.md is oversized and being truncated every turn

What I would do right now

Fast isolate

Clean up MEMORY.md

Verify memory subsystem

My priority order

What I’d do

1. Fix the memory backend first

2. Make provider selection explicit

3. Re-enable active-memory in a small, fast mode

4. Trim MEMORY.md

5. Turn logging off after tuning

My recommended rollout

3. Trim `MEMORY.md`

3. `MEMORY.md` is oversized and being truncated every turn

Clean up `MEMORY.md`

4. Trim `MEMORY.md`