#chutes AI models are making my server slow and its not responding normaly its very slow why ?

1 messages · Page 1 of 1 (latest)

steel pebble
#

chutes AI models are making my server slow and its not responding normaly its very slow why ?

onyx muralBOT
#

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

shadow sageBOT
#

Likely causes:

  • Chutes is a remote model provider, so slow replies can simply be model/API latency, queueing, rate limits, or a slow/overloaded model route.
  • If the assistant is doing tool-heavy work, the Gateway can look “stuck” because one session is waiting on a long model/tool call.
  • If your VPS/server is small, multiple sessions, browser automation, or large context/history can make the Gateway feel sluggish even if Chutes itself is the bottleneck.
  • Some non-Anthropic/OpenAI-style providers can be less reliable with tool calling/streaming, which may look like hanging or very slow responses.

First thing: what version are you on?

openclaw --version
openclaw status --all

If you can paste the redacted openclaw status --all output, it’ll show whether the gateway is unhealthy, overloaded, or just waiting on the model provider. You can also try switching to a known-stable model temporarily; if the server becomes responsive again, Chutes/model latency is probably the issue.

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/concepts/models

steel pebble
#

OpenClaw status

Overview
┌──────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────┤
│ OS │ linux 6.8.0-111-generic (x64) · node 22.22.0 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale exposure │ off │
│ Channel │ stable (default) │
│ Update │ available · pnpm · npm update 2026.5.7 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 268ms · auth token · vmi3114931 (31. │
│ │ 220.85.133) app 2026.5.4 linux 6.8.0-111-generic │
│ Gateway self │ vmi3114931 (31.220.85.133) app 2026.5.4 linux 6.8.0-111-generic │
│ Gateway service │ systemd user installed · enabled · running (pid 3410, state active) │
│ Node service │ systemd user not installed │
│ Agents │ 6 · no bootstrap files · sessions 13 · default main active 6m ago │
│ Memory

shadow sageBOT
#

Thanks — this already shows a couple useful clues:

  • You’re on OpenClaw 2026.5.4 and an update to 2026.5.7 is available. I’d update first; performance/provider issues may already be fixed.
  • Gateway is reachable but 268ms on local loopback is a little high. Not catastrophic, but it suggests the server may be busy.
  • You have 6 agents and 13 sessions. If several are active or stuck waiting on Chutes, that can make everything feel slow.

Try this first:

pnpm add -g openclaw@latest
openclaw gateway restart
openclaw status --all

Then check what’s actually eating time/resources:

# 
openclaw logs --follow
htop

If CPU/RAM is fine but logs show long waits around model calls, it’s probably Chutes latency/queueing/model route, not your server. Quick test: switch one session to a more stable/cloud model temporarily. If replies become normal, Chutes is the bottleneck.

Also paste the rest of openclaw status --all if you can — especially the provider/model/runtime sections. Tokens should be redacted automatically.

steel pebble
#

Channels
┌──────────┬─────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config×6 (8607…3jrQ · len 46) · accounts 6/6 │
└──────────┴─────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────┘

Sessions
┌────────────────────────────────────────┬────────┬─────────┬──────────────────────────┬─────────────────────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├────────────────────────────────────────┼────────┼─────────┼──────────────────────────┼─────────────────────────────────┤
│ agent:entry-mama-5:telegram:dir… │ direct │ 1m ago │ moonshotai/Kimi-K2.5-TEE │ 24k/262k (9%) │
│ agent:main:main │ direct │ 6m ago │ gpt-5.4 │ 116k/272k (43%) · 🗄️ 98% cached │
│ agent:entry-mama:telegram:direc… │ direct │ 19m ago │ moonshotai/Kimi-K2.5-TEE │ 42k/262k (16%) · 🗄️ 3% cached │
│ agent:entry-mama-2:telegram:dir… │ direct │ 19m ago │ moonshotai/Kimi-K2.5-TEE │ 21k/262k (8%) · 🗄️ 1% cached │
│ agent:entry-mama-3:telegram:dir… │ direct │ 19m ago │ moonshotai/Kimi-K2.5-TEE │ 20k/262k (8%) · 🗄️ 75% cached │
│ agent:entry-mama-4:telegram:dir… │ direct │ 19m ago │ moonshotai/Kimi-K2.5-TEE │ 21k/262k (8%) · 🗄️ 72% cached │
│ agent:main:telegram:direct:8756… │ direct │ 28m ago │ gpt-5.4 │ 45k/272k (17%) · 🗄️ 8% cached │
│ agent:entry-mama-4:telegram:sla… │ direct │ 8d ago │ moonshotai/Kimi-K2.5-TEE │ unknown/262k (?%) │
│ a/Ki

shadow sageBOT
#

Yep — this points much more strongly at concurrency + model latency, not “OpenClaw randomly being slow”.

You have 6 Telegram accounts enabled and several active sessions using moonshotai/Kimi-K2.5-TEE, all around the same time:

  • 5 entry-mama-* sessions active within ~1–19 minutes
  • each has ~20k–42k tokens of context
  • one main session has 116k tokens

That means your gateway may be juggling multiple long-context model calls. If those are routed through Chutes and Chutes is slow/queued, OpenClaw will feel unresponsive because sessions are waiting on remote model responses.

I’d do this in order:

  1. Update OpenClaw first — you’re on 2026.5.4 and 2026.5.7 is available.
pnpm add -g openclaw@latest
# 
openclaw gateway restart

  1. Temporarily reduce concurrency: disable some of the 6 Telegram accounts/agents or stop sending requests to all of them at once.

  2. Test one agent with a different stable model/provider. If it becomes fast, Chutes/Kimi latency is the bottleneck.

  3. Start fresh sessions for huge threads. 116k context can be expensive/slow even with caching.

  4. Watch logs while sending one message:

openclaw logs --follow

If the log sits waiting on model/API calls, your server isn’t the main problem — it’s waiting for Chutes/model responses. If CPU/RAM spikes in htop, then the VPS is too small or too many agents are active at once.

steel pebble
#

1r
2T
MemT
Swp[

0.7%]
1.3%]
0.7%1
729M/11.7G] Tasks: 30, 37 thr, 113 kthr; 2 running
ØK/0K] Load average: 0.94 0.62 0.65
Uptime: 02:04:40

4T
51

1.3%1
|99.3%]
1.3%1

Main
PID USER
3410 root
3623 root
3412 root
3413 root
3414 root
3415 root
3660 root
1 root
345 root
393 root
408 root

I/0

PRI
20
20
20
20
20
20
20
20
19
RT

NI

Command

S

0 25980

VIRT
0 21.7G
8920
0 21.7G
0 21.7G
0 21.7G
0 21.7G
0 14088
0 22044 13224
-1 34124 14744
282M 27452
7800

RES
567M 62984 R
4856
567M 62984 S
567M 62984 S
567M 62984 S
567M 62984 S
9624

SHR S

3624 R

8212 S
9512 S
13548 S
8760
5132 S

CPU%VMEM%
4.7 18:45.25 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index. js gateway -- port 187
0.0
4.7
4.7
4.7
4.7
0.1
0.1
0.1
0.2
0.1

99.8
1.3
0.7
0.7
0.7
0.7
0.7
0.0
0.0
0.0
0.0

TIME+

0:04.71 htop
0:22.38 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index. js gateway -- port 187
0:22.32 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index. js gateway -- port 187
0:22.15 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index. js gateway -- port 187
0:22.13 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index. js gateway -- port 187
0:00.19 sshd: root [priv]
0:05.08 /sbin/init
0:05.24 /usr/lib/systemd/systemd-journald
0:00.55 /sbin/multipathd -d -s
0:00.28 /usr/lib/svstemd/svstemd-udevd
what are this why they are consuming a lot of cpu

shadow sageBOT
#

Those rows are mostly the same OpenClaw Gateway process shown multiple times as threads in htop, not 5 separate gateways.

A few important bits:

  • /usr/bin/node ... openclaw/dist/index.js gateway --port 18789 = your OpenClaw Gateway.
  • VIRT 21.7G looks scary but is virtual address space, not real RAM usage. Node/V8 reserves a lot. Don’t worry about that number.
  • RES 567M is the real resident memory. That’s normal-ish for a gateway with multiple Telegram accounts/sessions.
  • Mem 729M/11.7G means RAM is fine.
  • Load average around 0.94 is not terrible.
  • If one row is really at 99.8% CPU, that means OpenClaw is using about one full CPU core. With your 6 Telegram accounts and active model sessions, that can happen, but it should not stay there forever.

In htop, press H to hide threads. Then you’ll see the real process list more clearly.

The bigger issue is probably not RAM — it’s either:

  1. many Telegram agents/sessions active at once, or
  2. OpenClaw waiting/retrying slow Chutes model calls, or
#
  1. a session/tool loop making the gateway busy.

Please check logs while it is slow:

openclaw logs --follow

Look for repeated errors, retries, rate limits, or model request timeouts. Also update from 2026.5.4 to 2026.5.7 first if possible; you’re a few patch versions behind.

steel pebble
#

:hannels/telegram {"subsystem":"channels/telegram"} telegram sendMessage ok chat=8756337759 message=501
18:44:06+00:00 warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=43s eventLoopDelayP99Ms=24964.5 eventLoopDelayMaxMs=24964.5 eventLoopUtilization=1 cpuCoreRatio=1.078 active=1 waiting=0 queued=1 phase=channels.telegram.start-account recentPhases=sidecars.subagent-recovery:11ms,sidecars.main-session-recovery:12ms,post-attach.update-sentinel:0ms,sidecars.model-prewarm:2344ms,sidecars.session-locks:2479ms,post-ready.maintenance:13ms work=[active=agent:entry-mama-5:telegram:direct:8756337759(processing,q=1,age=52s last=run:completed) queued=agent:entry-mama-5:telegram:direct:8756337759(processing,q=1,age=52s last=run:completed)]
18:44:06+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 451ms conn=057e7984…ffe4 id=412f31b9…a8b8
18:44:13+00:00 warn agent/embedded {"subsystem":"agent/embedded"} [trace:embedded-run] prep stages: runId=7a50f282-b1b4-4818-a9ec-79f63be35982 sessionId=654e931b-966c-4da3-a4fe-6a4d0d3f3129 phase=stream-ready totalMs=6871 stages=workspace-sandbox:14ms@14ms,skills:0ms@14ms,core-plugin-tools:1092ms@1106ms,bootstrap-context:83ms@1189ms,bundle-tools:195ms@1384ms,system-prompt:5219ms@6603ms,session-resource-loader:235ms@6838ms,agent-session:2ms@6840ms,stream-setup:31ms@6871ms
18:44:20+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 5840ms conn=057e7984…ffe4 id=b9e15696…5ffc
18:44:28+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 5263ms conn=057e7984…ffe4 id=f207e880…092d
18:44:30+00:00 info channels/telegram {"subsystem":"channels/telegram"} telegram sendMessage ok chat=8756337759 message=502
Log tail truncated (increase --max-bytes).
18:45:22+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 65ms conn=3245eb22…a282 id=040ab48a…7021

shadow sageBOT
#

This log explains the slowdown pretty clearly:

liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
eventLoopDelayP99Ms=24964.5
eventLoopUtilization=1
cpuCoreRatio=1.078
phase=channels.telegram.start-account
active=agent:entry-mama-5...
queued=agent:entry-mama-5...

Meaning:

  • The Gateway’s Node.js event loop was blocked for up to ~25 seconds. That is why it feels frozen/slow.
  • eventLoopUtilization=1 means the event loop was basically 100% busy during that interval.
  • cpuCoreRatio=1.078 means it was using about one full CPU core.
#
  • It happened while starting/handling a Telegram account: phase=channels.telegram.start-account.
  • One Telegram session was active and another message for the same session was queued.

So this is not mainly RAM. Your RAM is fine. It’s CPU/event-loop pressure from OpenClaw processing Telegram/model/session work.

What I’d do now:

  1. Update first — you’re on 2026.5.4 and should test 2026.5.7.
pnpm add -g openclaw@latest
openclaw gateway restart

  1. Reduce Telegram concurrency temporarily. You have 6 Telegram accounts; disable some or stop sending to all at once.

  2. Start fresh sessions for the busiest agents, especially ones with big context.

#
  1. If it still happens after update, capture a larger log around the warning:
openclaw logs --tail 300 --max-bytes 200000

If this repeats on 2026.5.7 with only one Telegram account active, that’s worth filing as a GitHub issue: https://github.com/openclaw/openclaw/issues

steel pebble
#

Stopping managed gateway service before package update...
Stopped systemd service: openclaw-gateway.service
│
◇ ✓ Updating via package manager (49.07s)
│
◇ ✓ Running doctor checks (71.91s)

Update Result: OK
Root: /usr/lib/node_modules/openclaw
Before: 2026.5.4
After: 2026.5.7

Total time: 129.17s

Updating plugins...
npm plugins: 0 updated, 1 unchanged.

shadow sageBOT
#

Nice, update succeeded 🎉

Now restart/confirm the gateway and re-test with one message only:

openclaw gateway restart
openclaw status --all
openclaw logs --follow

Then send one Telegram message to the slow agent and watch whether the liveness warning comes back.

If it’s still slow after 2026.5.7, the next best isolation test is:

  1. temporarily disable 5 of the 6 Telegram accounts/agents
  2. keep only one entry-mama-* account active
  3. test again
#

If one account is fine but six accounts are slow, it’s concurrency/load. If one account still triggers event_loop_delay / eventLoopUtilization=1, then it’s likely a bug or heavy session/tool loop and worth opening an issue with the log snippet: https://github.com/openclaw/openclaw/issues

steel pebble
#

18:56:15+00:00 warn gateway/ws {"subsystem":"gateway/ws"} handshake timeout conn=f2401904-b6a0-40c3-b474-b36f3ef3140a peer=127.0.0.1:43132->127.0.0.1:18789 remote=127.0.0.1
18:56:15+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"handshake-timeout","handshake":"failed","durationMs":18190,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"30d2f692-f9d8-4902-b375-91daae5f01ea","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":43132,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:43132->127.0.0.1:18789","handshakeMs":18168} closed before connect conn=f2401904-b6a0-40c3-b474-b36f3ef3140a peer=127.0.0.1:43132->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1000 reason=n/a
18:56:15+00:00 error gateway connect failed: Error: gateway closed (1000):
18:56:15+00:00 error gateway connect failed: Error: gateway closed (1000):
Log tail truncated (increase --max-bytes).
18:56:23+00:00 warn agent/embedded {"subsystem":"agent/embedded"} [trace:embedded-run] prep stages: runId=442e2432-f781-4443-a64e-7c03c8c92aec sessionId=654e931b-966c-4da3-a4fe-6a4d0d3f3129 phase=stream-ready totalMs=8030 stages=workspace-sandbox:23ms@23ms,skills:0ms@23ms,core-plugin-tools:576ms@599ms,bootstrap-context:295ms@894ms,bundle-tools:1323ms@2217ms,system-prompt:5633ms@7850ms,session-resource-loader:155ms@8005ms,agent-session:3ms@8008ms,stream-setup:22ms@8030ms
18:56:30+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 5399ms conn=d5160f53…6056 id=9a50791c…d562
18:56:30+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 178ms conn=d5160f53…6056 id=2d0342a2…e404

shadow sageBOT
#

This is the same root problem showing up in a different place.

handshake timeout on 127.0.0.1 means even the local CLI/dashboard tried to connect to the Gateway, but the Gateway didn’t finish the WebSocket handshake for 18 seconds. Since it’s localhost, this is almost certainly not internet/network — it means the Gateway event loop was too busy or blocked.

The useful lines are:

handshakeMs=18168
phase=stream-ready totalMs=8030
system-prompt:5633ms
bundle-tools:1323ms
chat.history 5399ms

So the Gateway is spending seconds preparing an agent run and loading/building prompt/tool/session state. Combined with the earlier eventLoopDelayP99Ms=24964, that explains why it feels frozen.

Do this next to isolate it:

#
  1. Restart cleanly after the update:
openclaw gateway restart

  1. Stop/disable the extra Telegram accounts temporarily. Test with only one account/agent active.

  2. Start a fresh chat/session for that agent if possible. Your existing sessions have fairly large context, and prompt building is already taking ~5–8s.

  3. While testing one message, run:

openclaw logs --follow --max-bytes 200000

If with only one Telegram account + fresh session it still shows event_loop_delay or handshake timeout, file a GitHub issue with these log lines: https://github.com/openclaw/openclaw/issues

Short version: your server RAM is fine; the Gateway’s Node event loop is getting blocked/busy. Chutes may still be slow for model responses, but these logs show local Gateway pressure too.

steel pebble
#

18:58:36+00:00 warn fetch-timeout {"subsystem":"fetch-timeout"} {"timeoutMs":10000,"elapsedMs":11023,"operation":"fetchWithTimeout","url":"https://api.telegram.org/bot874453…-8NY/getMe"} fetch timeout reached; aborting operation
18:59:03+00:00 warn fetch-timeout {"subsystem":"fetch-timeout"} {"timeoutMs":10000,"elapsedMs":26191,"timerDelayMs":16191,"eventLoopDelayHint":"timer delayed 16191ms, likely event-loop starvation","operation":"fetchWithTimeout","url":"https://api.telegram.org/bot861827…0lOo/getMe"} fetch timeout reached; aborting operation
18:59:03+00:00 warn gateway/ws {"subsystem":"gateway/ws"} handshake timeout conn=a39d3ce1-28f1-4a7f-bbcf-c17dae37da81 peer=127.0.0.1:48734->127.0.0.1:18789 remote=127.0.0.1
18:59:03+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"handshake-timeout","handshake":"failed","durationMs":26708,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"b9a07ebe-cecf-4e25-a678-9632035fe673","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":48734,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:48734->127.0.0.1:18789","handshakeMs":26634} closed before connect conn=a39d3ce1-28f1-4a7f-bbcf-c17dae37da81 peer=127.0.0.1:48734->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1005 reason=n/a
18:59:03+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 162ms conn=d5160f53…6056 id=308bcd25…6042
18:59:03+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 194ms conn=e548e9b0…db37 id=f3fdbe8a…0414

shadow sageBOT
#

This confirms it: the Gateway’s event loop is starving.

Key line:

timerDelayMs=16191
eventLoopDelayHint="timer delayed 16191ms, likely event-loop starvation"

That means a 10s Telegram getMe timeout didn’t fire until ~26s because Node was too busy to even run the timer. So Telegram isn’t necessarily the cause by itself — it’s a symptom plus startup pressure from multiple Telegram accounts.

Most likely cause in your setup: 6 Telegram bot accounts starting/checking at once + active long-context sessions, all inside one Gateway process.

Do this now:

  1. Restart once after update:
# 
openclaw gateway restart

  1. Temporarily disable all but one Telegram account in your config, then restart again.

  2. Test one message. If the warnings disappear, re-enable accounts one by one.

  3. If it still happens with only one Telegram account, collect:

openclaw status --all
openclaw logs --tail 500 --max-bytes 300000

and file it here: https://github.com/openclaw/openclaw/issues

Also: don’t judge by VIRT in htop. Your RAM is fine. The problem is the single Node event loop getting blocked, which is why local dashboard/CLI handshakes also timeout.

steel pebble
#

19:07:14+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 414ms conn=d5160f53…6056 id=32f757cd…410e
19:09:02+00:00 info gateway {"subsystem":"gateway"} signal SIGTERM received
19:09:02+00:00 info gateway {"subsystem":"gateway"} received SIGTERM; shutting down
19:09:02+00:00 info gateway/shutdown {"subsystem":"gateway/shutdown"} shutdown started: gateway stopping
19:09:02+00:00 info gmail-watcher {"subsystem":"gmail-watcher"} gmail watcher stopped
19:09:03+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1012 reason=service restart conn=d5160f53-afc3-402c-977e-5599be266056
19:09:03+00:00 info gateway/shutdown {"subsystem":"gateway/shutdown"} shutdown completed cleanly in 1083ms

shadow sageBOT
#

That part is normal — it just shows the gateway was restarted cleanly:

signal SIGTERM received
shutting down
webchat disconnected code=1012 reason=service restart
shutdown completed cleanly

SIGTERM here is expected when you run openclaw gateway restart or the updater restarts the service. Nothing scary in that snippet.

Now check the logs after it starts again. The important question is whether the old warnings come back:

  • event-loop starvation
  • event_loop_delay
  • handshake timeout
  • Telegram getMe timeouts with big timerDelayMs
#

Run:

openclaw gateway status
openclaw logs --tail 200 --max-bytes 200000

If the restart is clean and those warnings stop, the update/restart helped. If they return, reduce Telegram accounts to one and test again.

steel pebble
#

Service: systemd user (disabled)
File logs: /tmp/openclaw/openclaw-2026-05-13.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

shadow sageBOT
#

Now the gateway is simply not running.

Important lines:

Service: systemd user (disabled)
Runtime: stopped
Connectivity probe: failed
connect ECONNREFUSED 127.0.0.1:18789

So the slowness problem is paused for the moment — there is no gateway listening on port 18789.

Start it again with:

# 
openclaw gateway start

Then check:

openclaw gateway status
openclaw status --all

If you want it to auto-start after reboot/login, enable/install the service again. Depending on your setup, try:

openclaw gateway install --force
openclaw gateway start