OpenClaw is so slow after updating to 2026.4.25 | Friends of the Crustacean 🦞🤝 | Page 1

wintry elbow Apr 27, 2026, 2:53 PM

#

A few hours ago I updated to 2026.4.25, since then OpenClaw is so slow. I am using it in combination with telegram and even the messages I am writing are showing up in the control UI maybe 1 min after I wrote them in telegram. I am running it on an LXC on ProxMox. I also already checked the RAM, CPU, etc. utilization.

zinc crystalBOT Apr 27, 2026, 2:53 PM

#

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

strong oakBOT Apr 27, 2026, 2:55 PM

#

Hmm, if Telegram messages themselves reach Control UI ~1 min late, that’s probably Telegram polling / network / gateway event-loop delay, not the model.

2026.4.25 is the latest right now, so I’d grab diagnostics first:

openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw channels logs --channel telegram

Then keep logs open, send one Telegram test message, and look for getUpdates, Polling stall detected, fetch failed, 409 Conflict, or DNS/IPv6 errors:

openclaw logs --follow

#

On LXC/Proxmox I’d especially suspect IPv6/TLS egress to api.telegram.org. Quick check:

time curl -4 -sS -o /dev/null https://api.telegram.org
time curl -6 -sS -o /dev/null https://api.telegram.org

If IPv6 is slow/broken, try forcing Telegram networking away from auto family selection:

{
  channels: {
    telegram: {
      network: {
        autoSelectFamily: false
      }

#

    }
  }
}

Then restart:

openclaw gateway restart

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/channels/telegram#troubleshooting

If the logs show this started cleanly after 2026.4.25 with no network errors, please file a GitHub issue with openclaw status --all + the Telegram log snippet: https://github.com/openclaw/openclaw/issues 🦐

wintry elbow Apr 27, 2026, 3:26 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

|
OpenClaw status --all

Overview
┌────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.4.25 │
│ OS │ linux 6.8.12-20-pve (x64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://192.168.178.198:18789/ │
│ Tailscale exposure │ off │
│ Channel │ stable (default) │

#

│ Update │ pnpm · up to date · npm latest 2026.4.25 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (timeout) │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 189, state active) │

strong oakBOT Apr 27, 2026, 3:26 PM

#

Thanks — this only shows the Overview bit, the useful part got cut off.

Can you paste the rest of openclaw status --all, especially:

Gateway / connectivity probe
Channels / Telegram
Runtime issues
Recent log tail

Also please run this while sending one Telegram test message:

openclaw logs --follow

I’m looking for Telegram lines like:

#

getUpdates
Polling stall detected
fetch failed
409 Conflict
DNS / IPv6 / TLS errors
anything taking ~45–60s

If the Control UI gets the message late, the delay is happening before the agent run, so the Telegram polling/log lines are the key part. Docs for the relevant checks: https://docs.openclaw.ai/channels/telegram#troubleshooting

wintry elbow Apr 27, 2026, 3:26 PM

#

│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 1 active · 15 sessions │
│ Secrets │ none │
└────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ ABSENT │ 15 │ just now │ ~/.openclaw/agents/main/sessions/sessions.json │

#

────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: lan

✓ Config: /root/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 189 root: openclaw-gateway (*:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 16 eligible · 0 missing · /root/.openclaw/workspace
✓ Plugin compatibility (none)

Gateway restart attempts (tail): /root/.openclaw/logs/gateway-restart.log
[2026-04-24T12:49:38Z] openclaw restart attempt source=update target=openclaw-gateway.service
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
[2026-04-24T12:49:38Z] openclaw restart failed source=update status=1
[2026-04-24T17:46:02Z] openclaw restart attempt source=update target=openclaw-gateway.service
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
[2026-04-24T17:46:02Z] openclaw restart failed source=update status=1
[2026-04-27T13:02:14Z] openclaw restart attempt source=update target=openclaw-gateway.service
Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
[2026-04-27T13:02:14Z] openclaw restart failed source=update status=1
! Channel issues skipped (gateway unreachable)

Gateway health:
timeout

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

strong oakBOT Apr 27, 2026, 3:27 PM

#

That line is the smoking gun:

Gateway service: systemd ... running
Gateway: ws://127.0.0.1:18789 ... unreachable (timeout)

So systemd has a process, but the Gateway RPC is not responding locally. That explains Telegram → Control UI lag; it’s likely a wedged/blocked gateway, not Telegram itself.

Before restarting, grab the logs:

openclaw gateway status --deep
openclaw logs --follow

And in another shell:

#

curl -v --max-time 5 http://127.0.0.1:18789/healthz
curl -v --max-time 5 http://127.0.0.1:18789/readyz
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Then try the quick unstick:

openclaw gateway restart

If it comes back fast after restart but slows again, please paste the log section around startup + the first timeout. We’re looking for something blocking startup/event loop, channel init, plugin deps, or repeated Telegram polling restarts.

Docs: https://docs.openclaw.ai/gateway/troubleshooting

wintry elbow Apr 27, 2026, 3:27 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — I don't sleep, I just enter low-power mode and dream of clean diffs.

|
o
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.178.198:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 189, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

pid 189 root: openclaw-gateway (*:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

strong oakBOT Apr 27, 2026, 3:28 PM

#

Yep — this is still pointing at the Gateway being wedged, not normal Telegram delay.

The empty Channels table isn’t useful yet because the CLI can’t RPC into the Gateway:

Gateway ... unreachable (timeout)

So status --all is mostly falling back to local files/session state.

Please grab these three outputs before/after a restart:

curl -v --max-time 5 http://127.0.0.1:18789/healthz
curl -v --max-time 5 http://127.0.0.1:18789/readyz
journalctl --user -u openclaw-gateway.service -n 300 --no-pager

#

Then:

openclaw gateway restart
openclaw gateway status --require-rpc

If --require-rpc still times out immediately after restart, that’s a startup/blocking bug. If it’s fine after restart but degrades later, send one Telegram message and paste the log section around when it starts lagging.

Docs for these checks: https://docs.openclaw.ai/gateway/troubleshooting

#

Aha — this explains it.

Your update tried to restart the Gateway, but all restart attempts failed because the Linux user-systemd bus is unavailable:

DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR not defined

So you now have a process holding port 18789, but the Gateway RPC/health check is timing out. First fix is a real service restart from inside the LXC as root:

loginctl enable-linger root || true
export XDG_RUNTIME_DIR=/run/user/0

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

#

systemctl --user status openclaw-gateway.service --no-pager

openclaw gateway status --require-rpc

If systemctl --user still cannot connect, try:

systemctl --machine=root@.host --user restart openclaw-gateway.service

Or the blunt recovery path is just rebooting the LXC.

After it’s responsive again, run:

#

openclaw doctor --fix
openclaw gateway install --force

That should repair/update the service metadata so future OpenClaw updates can restart the gateway properly.

wintry elbow Apr 27, 2026, 3:29 PM

#

die IP ist nicht http://127.0.0.1:18789/healthz sonder http://192.168.178.198

strong oakBOT Apr 27, 2026, 3:29 PM

#

That’s still the same wedged process:

pid 189 root: openclaw-gateway
Connectivity probe: failed / timeout

So don’t chase Telegram yet — local Gateway WS is timing out.

Two useful things now:

Grab logs from the file directly — openclaw logs may also hang because RPC is broken:

tail -n 250 /tmp/openclaw/openclaw-2026-04-27.log
journalctl --user -u openclaw-gateway.service -n 250 --no-pager

#

Actually restart/replace pid 189:

export XDG_RUNTIME_DIR=/run/user/0
systemctl --user restart openclaw-gateway.service
sleep 5
systemctl --user show openclaw-gateway.service -p MainPID -p ActiveState -p SubState
openclaw gateway status --require-rpc

If MainPID is still 189, the restart didn’t happen. In that case the cleanest LXC recovery is a container reboot, then immediately check:

openclaw gateway status --require-rpc

The Port 18789 is already in use line is not a second instance by itself — it’s the wedged gateway holding the port.

#

Ja, für den Browser von deinem PC aus ist es:

http://192.168.178.198:18789/

Für den Health-Check wäre es:

http://192.168.178.198:18789/healthz
http://192.168.178.198:18789/readyz

Aber: wenn du den Befehl innerhalb des LXC ausführst, ist 127.0.0.1:18789 korrekt. Dein Gateway sagt ja:

#

bind=lan (0.0.0.0)
Listening: *:18789
Probe target: ws://127.0.0.1:18789

0.0.0.0 bedeutet: lauscht auf allen Interfaces — also 127.0.0.1 innerhalb des Containers und 192.168.178.198 aus dem LAN sollten beide gehen.

Bitte teste im LXC:

curl -v --max-time 5 http://127.0.0.1:18789/healthz
curl -v --max-time 5 http://192.168.178.198:18789/healthz

Wenn 192.168... geht, aber 127.0.0.1 timed out, wäre das sehr ungewöhnlich und interessant. Wenn beide hängen, ist der Gateway-Prozess wirklich wedged.

wintry elbow Apr 27, 2026, 3:31 PM

#

Kann das etwas mit dem Problem zu tun haben?: - Found 1 session lock file. |
| - ~/.openclaw/agents/main/sessions/9ba8fded-4c6e-4919-ad6a-eed17eb1446b.jsonl.lock |
| pid=189 (alive) age=4m8s stale=no |
|

strong oakBOT Apr 27, 2026, 3:32 PM

#

Ja — kann zusammenhängen, aber bitte nicht manuell löschen, solange da steht:

pid=189 (alive)
stale=no

Das bedeutet: der aktuell laufende Gateway-Prozess 189 hält gerade einen Lock auf genau dieser Session. Das ist während einer aktiven Antwort normal.

Aber in deinem Fall ist pid=189 auch der Prozess, bei dem die Gateway-Probe timed out. Wenn dieser Lock länger stehen bleibt und nicht verschwindet, ist das eher ein Symptom: ein Run / eine Session hängt oder der Gateway-Prozess ist wedged.

Wichtig:

stale=no → nicht löschen
pid=189 alive → gehört zum laufenden Gateway
Wenn nach einem echten Restart/Reboot dort stale=yes oder PID tot steht → dann kann openclaw doctor --fix aufräumen

#

Ich würde jetzt wirklich den Prozess ersetzen:

export XDG_RUNTIME_DIR=/run/user/0
systemctl --user restart openclaw-gateway.service

oder wenn das in LXC weiter zickt: Container rebooten.

Danach prüfen:

openclaw gateway status --require-rpc

Wenn der Lock danach wieder sofort auftaucht und die Probe wieder hängt, brauchen wir den Log-Auszug rund um diese Session/den Start.

#

Docs: https://docs.openclaw.ai/gateway/troubleshooting

wintry elbow Apr 27, 2026, 3:32 PM

#

Und kann das etwas damit zu tun haben:?: |
o Bootstrap file size --------------------------------------------------+
| |
| Workspace bootstrap files are near configured limits: |
| - AGENTS.md: 11,252 chars (94% of max/file 12,000) |
| Total bootstrap injected chars: 20,570 (34% of max/total 60,000). |
| Total bootstrap raw chars (before truncation): 20,570. |
| |
| - Tip: tune agents.defaults.bootstrapMaxChars for per-file limits.

strong oakBOT Apr 27, 2026, 3:32 PM

#

Eher nein — das ist sehr wahrscheinlich nicht die Ursache für den 1‑Minuten-Delay.

Das bedeutet nur:

AGENTS.md: 94% vom per-file Limit
Total bootstrap: 34% vom total Limit

Wichtig: Es wurde offenbar nichts abgeschnitten:

injected chars = raw chars = 20,570

Das kann Agent-Antworten minimal teurer/langsamer machen, weil mehr Kontext geladen wird. Aber es erklärt nicht, warum:

#

Gateway health: timeout
Connectivity probe: failed

und warum Telegram-Nachrichten erst spät im Control UI auftauchen. Das ist Gateway/Event-loop/Prozess-Wedge, nicht Bootstrap-Größe.

Ich würde bootstrapMaxChars jetzt nicht erhöhen — das macht eher mehr Kontext, nicht weniger. Erst Gateway wirklich neu starten/rebooten, bis das hier klappt:

openclaw gateway status --require-rpc

Danach kann man AGENTS.md aufräumen, aber das ist Optimierung, nicht der Hauptfix.

Docs dazu: https://docs.openclaw.ai/concepts/context und https://docs.openclaw.ai/gateway/config-agents

wintry elbow Apr 27, 2026, 3:34 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — More integrations than your therapist's intake form.

|
o
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.178.198:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 855, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Read probe: failed
Probe target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json
Possible causes:

Gateway not yet ready to accept connections (retry after a moment)
TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
Gateway crashed or was terminated unexpectedly
Run openclaw doctor for diagnostics.

Gateway port 18789 is not listening (service appears running).
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Restart log: ~/.openclaw/logs/gateway-restart.log

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

strong oakBOT Apr 27, 2026, 3:34 PM

#

Gut: PID ist von 189 auf 855 gewechselt — der Restart hat also wirklich stattgefunden.

Jetzt ist der Fehler anders:

gateway closed (1006 abnormal closure)
Source: cli --url

Wichtig: Wenn du --url manuell nutzt, werden lokale Auth-Daten ggf. nicht automatisch genommen. Teste bitte ohne --url:

openclaw gateway status --require-rpc

Wenn das auch fehlschlägt, brauchen wir jetzt Logs — der Gateway-Prozess lebt, aber WS/HTTP ist nicht gesund:

#

curl -v --max-time 5 http://127.0.0.1:18789/healthz
curl -v --max-time 5 http://127.0.0.1:18789/readyz
tail -n 250 /tmp/openclaw/openclaw-2026-04-27.log
journalctl --user -u openclaw-gateway.service -n 250 --no-pager

Falls die Service-Datei durch die fehlgeschlagenen Update-Restarts stale ist, danach einmal reparieren:

openclaw gateway install --force
systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

Aber zuerst bitte die Log-Zeilen sichern — da sollte jetzt die eigentliche Ursache stehen.

wintry elbow Apr 27, 2026, 3:36 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'm the middleware between your ambition and your attention span.

|
o
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.178.198:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 855, state active, sub running, last exit 0, reason 0)
Read probe: ok
Capability: admin-capable

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@openclaw:~curl -v --max-time 5 http://127.0.0.1:18789/healthz

Trying 127.0.0.1:18789...
Connected to 127.0.0.1 (127.0.0.1) port 18789
using HTTP/1.x

GET /healthz HTTP/1.1
Host: 127.0.0.1:18789
User-Agent: curl/8.14.1
Accept: /

Request completely sent off

strong oakBOT Apr 27, 2026, 3:37 PM

#

Nice — das ist ein großer Fortschritt:

Read probe: ok
Capability: admin-capable
Listening: *:18789

Damit ist der Gateway selbst wieder erreichbar. Der Restart hat also den wedged Prozess repariert.

Der curl-Output ist noch abgeschnitten — wenn der nach 5s nicht mit einer Response zurückkommt, bitte posten, was danach kommt. Aber wichtiger ist jetzt wieder Telegram:

openclaw channels status --probe
openclaw logs --follow

#

Dann eine Testnachricht in Telegram senden und schauen, ob sie jetzt sofort im Control UI auftaucht.

Wenn es wieder langsam ist, poste die Logzeilen rund um die Testnachricht — speziell alles mit:

telegram
getUpdates
Polling stall
fetch failed
409
timeout

Und für die Zukunft: deine Update-Restarts sind vorher wegen fehlendem user-systemd env gescheitert. In der LXC/root-Session vor openclaw gateway restart/Updates ggf.:

#

export XDG_RUNTIME_DIR=/run/user/0
loginctl enable-linger root

Aber erstmal testen, ob Telegram nach dem echten Restart wieder normal schnell ist.

wintry elbow Apr 27, 2026, 3:37 PM

#

Apr 27 15:35:14 openclaw node[855]: 2026-04-27T15:35:14.997+00:00 [ws] ⇄ res ✓ status 439ms conn=c4322ec0…5eb6 id=93f84b29…e44f
Apr 27 15:35:15 openclaw node[855]: 2026-04-27T15:35:15.011+00:00 [plugins] embedded acpx runtime backend registered (cwd: /root/.openclaw/workspace)
Apr 27 15:35:15 openclaw node[855]: 2026-04-27T15:35:15.553+00:00 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
Apr 27 15:35:15 openclaw node[855]: 2026-04-27T15:35:15.563+00:00 [ws] ⇄ res ✓ cron.runs 1257ms conn=a042b127…fca8 id=cdf0445e…f4ef
Apr 27 15:35:15 openclaw node[855]: 2026-04-27T15:35:15.569+00:00 [telegram] [default] starting provider (@paulgerhardt_bot)
Apr 27 15:35:16 openclaw node[855]: 2026-04-27T15:35:16.186+00:00 [telegram] menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 60 commands visible.
Apr 27 15:35:16 openclaw node[855]: 2026-04-27T15:35:16.199+00:00 [plugins] bonjour: advertised gateway fqdn=openclaw._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
Apr 27 15:35:16 openclaw node[855]: 2026-04-27T15:35:16.225+00:00 [heartbeat] started
Apr 27 15:35:31 openclaw node[855]: 2026-04-27T15:35:31.921+00:00 [ws] webchat connected conn=9f985bd0-ca82-4a95-8e04-babe7036a62c remote=192.168.178.112 client=openclaw-control-ui webchat v2026.4.25
Apr 27 15:35:32 openclaw node[855]: 2026-04-27T15:35:32.584+00:00 [ws] ⇄ res ✓ channels.status 527ms conn=9f985bd0…a62c id=27210ad3…b05a
Apr 27 15:35:32 openclaw node[855]: 2026-04-27T15:35:32.597+00:00 [ws] ⇄ res ✓ node.list 540ms conn=9f985bd0…a62c id=508cad3f…806c
Apr 27 15:35:32 openclaw node[855]: 2026-04-27T15:35:32.599+00:00 [ws] ⇄ res ✓ device.pair.list 542ms conn=9f985bd0…a62c id=cffc9f16…026f
Apr 27 15:37:13 openclaw node[855]: 2026-04-27T15:37:13.862+00:00 [ws] ⇄ res ✓ commands.list 316ms conn=9f985bd0…a62c id=c01f7fa5…f7a3

strong oakBOT Apr 27, 2026, 3:38 PM

#

Die Logs sehen nach dem Restart erstmal gesund aus:

Read probe: ok
ws responses: 316–540ms
telegram starting provider
webchat connected

Das hier ist kein kritischer Fehler:

[telegram] menu text exceeded ... shortening descriptions

Heißt nur: zu viele/zu lange Telegram-Command-Beschreibungen, OpenClaw kürzt das Menü.

#

Was in deinem Ausschnitt noch fehlt: eine Telegram-Testnachricht. Bitte jetzt:

openclaw channels status --probe
openclaw logs --follow --plain

Dann in Telegram eine Nachricht senden. Wenn alles repariert ist, solltest du fast sofort Telegram-/Inbound-/Agent-Zeilen sehen und die Nachricht im Control UI sehen.

Wenn es wieder ~1 Minute dauert, poste genau den Log-Block ab dem Moment der Telegram-Nachricht. Dann schauen wir gezielt auf getUpdates, Polling-Stalls oder Netzwerk/IPv6.

wintry elbow Apr 27, 2026, 3:38 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — Shell yeah—I'm here to pinch the toil and leave you the glory.

|
o
Gateway reachable.

Telegram default: enabled, configured, running, connected, in:3m ago, mode:polling, bot:@paulgerhardt_bot, token:config, works

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

strong oakBOT Apr 27, 2026, 3:38 PM

#

Perfect — das sieht jetzt gesund aus:

Gateway reachable
Telegram ... running, connected ... works

Damit war die Hauptursache sehr wahrscheinlich der hängende alte Gateway-Prozess nach dem Update, weil der automatische Restart im LXC/root-user-systemd nicht sauber durchkam.

Jetzt bitte nur noch einmal real testen:

openclaw logs --follow --plain
Telegram-Nachricht senden
Schauen, ob sie sofort im Control UI auftaucht

Wenn es jetzt schnell ist: erledigt 🎉
Danach würde ich noch ausführen, damit zukünftige Restarts robuster sind:

#

loginctl enable-linger root
export XDG_RUNTIME_DIR=/run/user/0
openclaw gateway install --force
openclaw doctor

Wenn es trotz works wieder langsam wird, ist der nächste Verdächtige Telegram polling/network — dann brauchen wir den Log-Block während der Testnachricht.

wintry elbow Apr 27, 2026, 3:41 PM

#

Ja, bis mir die KI selber anwortet dauert es immernoch ewig! Auch bid die Nachrichten in der WebUI auftauchen dauert ewig! Hier noch ein paar Logs: 2026-04-27T15:33:59.590Z info plugins {"subsystem":"plugins"} bonjour: advertised gateway fqdn=openclaw._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
2026-04-27T15:35:13.335Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ chat.history 0ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup conn=a042b127…fca8 id=49b3a3bf…cd1c
2026-04-27T15:35:13.378Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ models.list 0ms errorCode=UNAVAILABLE errorMessage=models.list unavailable during gateway startup conn=a042b127…fca8 id=eb561806…0c73
2026-04-27T15:35:13.764Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 382ms conn=a042b127…fca8 id=299334a2…a7a0
2026-04-27T15:35:14.308Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 542ms conn=a042b127…fca8 id=c7f43206…1883
2026-04-27T15:35:14.317Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 986ms conn=a042b127…fca8 id=d65863ab…bbcf
2026-04-27T15:35:14.321Z warn plugins {"subsystem":"plugins"} bonjour: restarting advertiser (service stuck in announcing for 77268ms (gateway fqdn=openclaw._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
2026-04-27T15:35:14.525Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 1195ms conn=a042b127…fca8 id=aa6d7ff8…bedb
2026-04-27T15:35:14.528Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 1196ms conn=a042b127…fca8 id=9b1dbc59…ef18
2026-04-27T15:35:14.539Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ cron.status 236ms conn=a042b127…fca8 id=6877ea2b…68f3
2026-04-27T15:35:14.548Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ cron.list 244ms conn=a042b127…fca8 id=12b6c04a…a91b

#

2026-04-27T15:35:14.551Z info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=a042b127-8cdf-46cd-a4c8-de68eeaefca8
2026-04-27T15:35:14.996Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ status 439ms conn=c4322ec0…5eb6 id=93f84b29…e44f
2026-04-27T15:35:15.010Z info plugins {"subsystem":"plugins"} embedded acpx runtime backend registered (cwd: /root/.openclaw/workspace)
2026-04-27T15:35:15.552Z info browser/server {"subsystem":"browser/server"} Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T15:35:15.562Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ cron.runs 1257ms conn=a042b127…fca8 id=cdf0445e…f4ef
2026-04-27T15:35:15.568Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider (@paulgerhardt_bot)
2026-04-27T15:35:16.185Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 60 commands visible.
2026-04-27T15:35:16.199Z info plugins {"subsystem":"plugins"} bonjour: advertised gateway fqdn=openclaw._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
2026-04-27T15:35:16.224Z info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
2026-04-27T15:35:16.233Z info cron {"module":"cron","storePath":"/root/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":1,"nextWakeAtMs":1777352400000} cron: started

#

2026-04-27T15:35:31.920Z info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=9f985bd0-ca82-4a95-8e04-babe7036a62c remote=192.168.178.112 client=openclaw-control-ui webchat v2026.4.25
2026-04-27T15:35:32.583Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 527ms conn=9f985bd0…a62c id=27210ad3…b05a
2026-04-27T15:35:32.596Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 540ms conn=9f985bd0…a62c id=508cad3f…806c
2026-04-27T15:35:32.599Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 542ms conn=9f985bd0…a62c id=cffc9f16…026f
2026-04-27T15:37:13.861Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 316ms conn=9f985bd0…a62c id=c01f7fa5…f7a3
2026-04-27T15:37:48.027Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ models.list 34483ms conn=9f985bd0…a62c id=822712d1…d045
2026-04-27T15:37:48.043Z info typing TTL reached (2m); stopping typing indicator
2026-04-27T15:37:48.045Z warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=unknown sessionKey=*** state=processing age=136s queueDepth=1
2026-04-27T15:37:48.049Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 34566ms conn=9f985bd0…a62c id=fe90974d…7179
2026-04-27T15:37:48.321Z info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1006 reason=n/a conn=9f985bd0-ca82-4a95-8e04-babe7036a62c

#

2026-04-27T15:37:49.847Z info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=11f3fc0c-bfb9-4833-a285-1827328cf807 remote=192.168.178.112 client=openclaw-control-ui webchat v2026.4.25
2026-04-27T15:37:50.364Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 313ms conn=11f3fc0c…f807 id=715e32b1…0b66
2026-04-27T15:37:50.371Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ models.list 321ms conn=11f3fc0c…f807 id=dcb95aa8…9108
2026-04-27T15:37:50.385Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 391ms conn=11f3fc0c…f807 id=470d3017…957d
2026-04-27T15:37:50.387Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 393ms conn=11f3fc0c…f807 id=08d27cb7…f489
2026-04-27T15:38:14.463Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 632ms conn=6224b81e…6b60 id=255bd147…5a63
Log tail truncated (increase --max-bytes).
2026-04-27T15:40:18.046Z warn diagnostic {"subsystem":"diagnostic"} stuck session: sessionId=main sessionKey=*** state=processing age=148s queueDepth=1
2026-04-27T15:40:45.918Z error [tools] edit failed: Could not find the exact text in /root/.openclaw/workspace/AGENTS.md. The old text must match exactly including all whitespace and newlines.
Current file contents:

strong oakBOT Apr 27, 2026, 3:42 PM

#

Die Logs, die du gepostet hast, sind fast nur Startup/UI-RPC — die erklären den aktuellen Telegram-Delay noch nicht.

Kurz einordnen:

chat.history unavailable during gateway startup → normal direkt beim Start.
bonjour ... stuck in announcing → wahrscheinlich nicht die Ursache.
WS-Antworten mit 300–1200ms → WebSocket/Gateway wirkt nach Restart grundsätzlich okay.
Was fehlt: der Log-Block genau während du eine Telegram-Nachricht sendest.

Bitte so testen:

openclaw logs --follow --plain

Dann in Telegram eine Nachricht senden wie:

#

latency test 15:45

Und direkt danach in einem zweiten Terminal:

date -Ins
openclaw channels status --probe
openclaw gateway status --require-rpc

Wichtig ist die Unterscheidung:

Telegram-Log erscheint erst nach ~60s → Telegram polling/network/IPv6/getUpdates Problem.
Telegram-Log erscheint sofort, aber WebUI erst spät → Gateway/session/event-stream Problem.
Nachricht erscheint sofort in WebUI, aber KI antwortet spät → Modell/provider/agent run Problem.

#

Wenn möglich, setz kurzzeitig File-Logs auf debug, dann sehen wir mehr Telegram-Details:

openclaw config set logging.level debug
openclaw gateway restart
openclaw logs --follow --plain

Danach bitte wieder zurück auf info, sonst werden die Logs unnötig groß.

#

Ja — das Bonjour/mDNS-Ding ist jetzt verdächtig, gerade in LXC/Proxmox.

Diese Zeile passt zeitlich ziemlich gut zu deinem “~1 Minute” Problem:

bonjour: restarting advertiser (service stuck in announcing for 77268ms)

Bonjour ist nur LAN-Auto-Discovery. Du nutzt die feste URL http://192.168.178.198:18789/, also kannst du es testweise gefahrlos abschalten:

openclaw plugins disable bonjour
openclaw gateway restart

Dann prüfen:

#

openclaw gateway status --require-rpc
openclaw channels status --probe

Das sollte nicht Telegram oder Control UI über die direkte IP kaputtmachen — es deaktiviert nur mDNS/Bonjour Discovery.

Die anderen Zeilen sind eher normal beim Restart:

chat.history unavailable during gateway startup → normal während Startup
webchat disconnected code=1006 → normal, wenn Gateway gerade neu startet

Wenn es nach bonjour disable immer noch langsam ist, brauchen wir den Logblock genau ab dem Moment, wo du eine Telegram-Testnachricht sendest. Docs: https://docs.openclaw.ai/gateway/bonjour

#

Ja — das ist jetzt der wichtigste Logblock.

typing TTL reached (2m)
stuck session ... state=processing age=136s queueDepth=1

Das heißt: eine Session hängt seit >2 Minuten in processing, und mindestens eine neue Nachricht wartet dahinter. Deshalb fühlt sich Telegram/WebUI “ewig” an.

Erstmal den hängenden Run stoppen. In genau dem Telegram-Chat als einzelne Nachricht senden:

stop

oder:

#

abort

Falls das wegen Queue auch nicht schnell greift, per CLI:

openclaw sessions --active 30 --json

Darin den Telegram-Session-key suchen, dann:

openclaw gateway call sessions.abort --params '{"key":"HIER_DEN_KEY_EINSETZEN"}'

Zweite Auffälligkeit:

#

models.list 34483ms
node.list 34566ms

models.list dauert 34s — das ist viel zu langsam und kann die Control UI zusätzlich blockieren. Zum Gegencheck: Control UI Tabs schließen, nur Telegram + Logs testen. Wenn Telegram dann schneller ist, hängt ein Teil am Control-UI/model-list Pfad.

Danach bitte nochmal testen:

openclaw logs --follow --plain

Telegram-Nachricht senden und schauen, ob wieder stuck session kommt.

Docs zu Stop/Abort: https://docs.openclaw.ai/help/faq#chat-commands-aborting-tasks-and-it-will-not-stop

#

Ja — das ist jetzt ziemlich eindeutig:

stuck session ... state=processing age=148s queueDepth=1
edit failed ... AGENTS.md

Der Gateway/Telegram-Transport wirkt inzwischen okay. Es hängt jetzt ein Agent-Run, der offenbar versucht, AGENTS.md zu editieren, dabei scheitert und die Queue blockiert. Deshalb kommen neue Nachrichten/Antworten verzögert.

Mach zuerst einen Abort:

openclaw gateway call sessions.abort --params '{"key":"main"}'

Falls das nichts abbricht:

#

openclaw sessions --active 60 --json

Dann aus der Ausgabe den passenden key nehmen und:

openclaw gateway call sessions.abort --params '{"key":"DEN_KEY_HIER"}'

Alternativ im Telegram-Chat als einzelne Nachricht senden:

abort

oder:

#

stop

Danach direkt testen:

openclaw logs --follow --plain

und eine Telegram-Nachricht schicken.

Wenn es danach normal schnell ist, war’s der hängende Edit-Run. Wenn es sofort wieder passiert, sag der KI erstmal nicht weiter, sie soll AGENTS.md ändern — da scheint sie in einem fehlgeschlagenen Exact-Text-Edit zu hängen.

Docs: https://docs.openclaw.ai/help/faq#chat-commands-aborting-tasks-and-it-will-not-stop

wintry elbow Apr 27, 2026, 3:45 PM

#

|
o
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.178.198:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 1085, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Read probe: failed
Probe target: ws://127.0.0.1:18789
gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json

Port 18789 is already in use.

pid 1085 root: openclaw-gateway (*:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

strong oakBOT Apr 27, 2026, 3:46 PM

#

Jetzt ist es wieder Gateway selbst hängt, nicht Telegram:

Runtime: running
Listening: *:18789
Read probe: failed ... gateway timeout

Port already in use ist hier normal — das ist einfach der Gateway-Prozess selbst.

Bitte einmal nicht direkt nach Restart messen, sondern mit längerem Timeout:

sleep 60
openclaw gateway status --require-rpc --timeout 60000

#

Wenn das weiterhin hängt, brauchen wir direkt die letzten Logs aus Datei/journal, nicht via RPC:

tail -n 300 /tmp/openclaw/openclaw-2026-04-27.log
journalctl --user -u openclaw-gateway.service -n 300 --no-pager
ps -p 1085 -o pid,etime,stat,pcpu,pmem,wchan:32,cmd

Und falls noch nicht gemacht: Bonjour testweise deaktivieren, weil dein Log vorher stuck in announcing for 77s gezeigt hat und LXC/Proxmox mDNS oft kaputt ist:

openclaw plugins disable bonjour
openclaw gateway restart

Der andere echte Hinweis bleibt: stuck session ... queueDepth=1 + edit failed AGENTS.md. Sobald RPC wieder geht, diese Session aborten.

wintry elbow Apr 27, 2026, 3:49 PM

#

2026-04-27T15:45:50.184Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 583ms conn=c58383d3…ca73 id=a80ff656…99ff
2026-04-27T15:45:50.188Z info plugins {"subsystem":"plugins"} embedded acpx runtime backend registered (cwd: /root/.openclaw/workspace)
2026-04-27T15:45:50.497Z info browser/server {"subsystem":"browser/server"} Browser control listening on http://127.0.0.1:18791/ (auth=token)
2026-04-27T15:45:50.530Z info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
2026-04-27T15:45:50.550Z info cron {"module":"cron","storePath":"/root/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":1,"nextWakeAtMs":1777352400000} cron: started
2026-04-27T15:45:50.619Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider (@paulgerhardt_bot)
2026-04-27T15:45:51.040Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 60 commands visible.
2026-04-27T15:47:48.665Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"5d1f4e18-fa04-49f3-a228-dcb27f896585","stage":"assistant","decision":"surface_error","failoverReason":null,"profileFailureReason":null,"provider":"nvidia","model":"moonshotai/kimi-k2.5","sourceProvider":"nvidia","sourceModel":"moonshotai/kimi-k2.5","fallbackConfigured":true,"timedOut":false,"aborted":true} embedded run failover decision
2026-04-27T15:47:48.796Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8736947311 message=2655
2026-04-27T15:47:49.789Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8736947311 message=2656
2026-04-27T15:48:25.796Z info Gateway call: sessions.abort

strong oakBOT Apr 27, 2026, 3:49 PM

#

Das ist jetzt der eigentliche Kern:

provider="nvidia"
model="moonshotai/kimi-k2.5"
aborted=true
...
typing TTL reached (2m)
stuck session ... processing

Heißt: Telegram send/receive funktioniert, aber der Agent-Run beim Modell hängt ~2 Minuten, danach wird abgebrochen/failover. Dadurch staut sich die Queue und alles wirkt langsam.

Nächster Test: temporär auf einen anderen bereits konfigurierten Provider/Model wechseln und denselben Telegram-Test machen.

#

openclaw models status --probe
openclaw models status

Dann entweder im Control UI ein anderes Modell wählen oder per CLI dein gewünschtes Modell setzen:

openclaw models set <provider/model>
openclaw gateway restart

Wenn es mit einem anderen Modell sofort schnell ist, ist es ein NVIDIA/Kimi/provider-runtime Problem, nicht Telegram/LXC.

Für frische Modell-Empfehlungen bitte auch in #models schauen/fragen; die ändern sich zu schnell. Docs: https://docs.openclaw.ai/concepts/models

wintry elbow Apr 27, 2026, 3:52 PM

#

🦞 OpenClaw 2026.4.25 (aa36ee6) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : nvidia/moonshotai/kimi-k2.5
Fallbacks (5) : openrouter/openrouter/elephant-alpha, groq/groq/compound, nvidia/nvidia/mistral-nemo-minitron-8b-8k-instruct, nvidia/meta/llama-3.3-70b-instruct, nvidia/nvidia/llama-3.1-nemotron-70b-instruct
Image model : -
Image fallbacks (0): -
Aliases (2) : Auto (Free Router) -> openrouter/openrouter/free, gemini -> google/gemini-3.1-pro-preview
Configured models (15): openrouter/openrouter/free, openrouter/openrouter/elephant-alpha, openrouter/google/gemma-4-31b-it:free, openrouter/google/gemma-4-26b-a4b-it:free, google/gemini-3.1-pro-preview, google/gemini-2.5-flash, groq/groq/compound, groq/llama-3.3-70b-versatile, groq/qwen/qwen-3-32b, nvidia/moonshotai/kimi-k2.5, nvidia/nvidia/llama-3.1-nemotron-70b-instruct, nvidia/meta/llama-3.3-70b-instruct, nvidia/nvidia/mistral-nemo-minitron-8b-8k-instruct, nvidia/deepseek/deepseek-v4-flash, nvidia/mistralai/mistral-small-4-119b-2603

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openrouter (1)

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAi...5EZHYBAg
groq effective=env:gsk_nyN2...mXzpd207 | env=gsk_nyN2...mXzpd207 | source=env: GROQ_API_KEY
nvidia effective=models.json:nvapi-dQ...PnIdGvJ4 | models.json=nvapi-dQ...PnIdGvJ4 | source=models.json: ~/.openclaw/agents/main/agent/models.json
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | openrouter:default=sk-or-v1...c146ec50, openrouter:manual=token:sk-or-v1...414bac6d

OAuth/token status

openrouter
- openrouter:manual static

strong oakBOT Apr 27, 2026, 3:52 PM

#

Yep — this confirms the direction.

Your default is:

nvidia/moonshotai/kimi-k2.5

And the earlier log showed that exact provider/model run getting aborted after the long delay. So I’d stop debugging Telegram for now; Telegram is connected and working. The slow part is the agent/model run.

Do this test:

openclaw gateway call sessions.abort --params '{"key":"main"}'
openclaw models set <pick-one-non-nvidia-model-from-your-configured-list>
openclaw gateway restart

#

Then send a simple Telegram message.

If it’s fast with Groq/OpenRouter/Google but slow with NVIDIA/Kimi, then the culprit is the NVIDIA/Kimi path or that API key/provider state.

Also run:

openclaw models status --probe

Look specifically for NVIDIA probe errors/timeouts/cooldowns.

One more thing: your auth output is redacted, good — but don’t paste full API keys if any command ever prints them. For fresh model recommendations, best place is #models; I don’t want to give stale model advice. Docs: https://docs.openclaw.ai/concepts/models

wintry elbow Apr 27, 2026, 3:59 PM

#

Wie kann ich denn auf die Version vor der 2026.4.24 downgraden?

strong oakBOT Apr 27, 2026, 4:00 PM

#

Die Version direkt vor 2026.4.24 ist 2026.4.23.

Sauberster Weg: den OpenClaw-Updater auf exakt diese Version pinnen, damit er den Install-Typ nicht vermischt:

openclaw backup create --verify
export XDG_RUNTIME_DIR=/run/user/0

openclaw update --tag openclaw@2026.4.23 --yes --no-restart
openclaw gateway install --force
openclaw gateway restart

openclaw --version
openclaw gateway status --require-rpc

Damit er sich nicht direkt wieder auto-updated:

#

openclaw config set update.auto.enabled false

Falls du manuell via pnpm global installiert hattest, wäre der Fallback:

pnpm add -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart

Docs: https://docs.openclaw.ai/install/updating

novel hare Apr 27, 2026, 4:28 PM

#

same here...
2026.4.25 is really slow 🙁

strong oakBOT Apr 27, 2026, 4:29 PM

#

Yeah, that’s useful signal — if multiple people see 2026.4.25 slow, please grab diagnostics before downgrading if you can:

openclaw status --all
openclaw gateway status --require-rpc
openclaw channels status --probe
openclaw logs --follow --plain

Look for lines like:

Read probe: failed / gateway timeout
stuck session
typing TTL reached
embedded_run_failover_decision

#

models.list ... 30000ms+
telegram getUpdates / Polling stall

If you need the quick workaround, downgrade to the version before 2026.4.24:

openclaw backup create --verify
openclaw update --tag openclaw@2026.4.23 --yes --no-restart
openclaw gateway install --force
openclaw gateway restart

Then please file a GitHub issue with the log snippets/status output so maintainers can track the regression: https://github.com/openclaw/openclaw/issues

wanton sparrow Apr 27, 2026, 5:07 PM

#

Same here. I filed a bug report here: https://github.com/openclaw/openclaw/issues/72933

strong oakBOT Apr 27, 2026, 5:07 PM

#

Thanks — that issue looks very relevant. It’s specifically about 2026.4.25 rebuilding bundled plugin mirrors on every plugin load/reconnect, causing lots of small disk writes and event-loop stalls on slower storage. That matches the “gateway feels slow / messages arrive late” pattern people are seeing. (github.com)

For anyone else affected: please add your openclaw status --all, storage type, enabled channels, and log snippets to #72933 rather than opening scattered duplicates. Useful log clues: slow models.list/node.list, stuck session, gateway probe timeouts, or bursts under ~/.openclaw/plugin-runtime-deps.

Short-term mitigations:

downgrade to 2026.4.23, or
if you’re comfortable with it, move OPENCLAW_PLUGIN_STAGE_DIR to tmpfs/ramdisk as the issue author did.

GitHub

Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

novel hare Apr 28, 2026, 8:14 AM

#

upgrading to newer version solved it for me!

strong oakBOT Apr 28, 2026, 8:14 AM

#

Nice, glad updating fixed it! 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for future users. 🦐

wintry elbow Apr 29, 2026, 3:35 PM

#

So I am now also at 2026.4.26 and it is still so slow

strong oakBOT Apr 29, 2026, 3:40 PM

#

Yep — if the Telegram message itself only appears in Control UI ~1 min later, that’s before the model, so I’d treat this as Gateway/Telegram ingestion latency.

2026.4.25 did touch Telegram polling/webhook behavior, so this is plausible regression territory. (api.github.com)

Can you paste these outputs?

openclaw status --all
openclaw gateway status
openclaw channels status --probe

Then run this, send one Telegram message, and note the exact time:

date -u

#

openclaw logs --follow --local-time

If the log entry is delayed too → Telegram polling/network/LXC issue. If logs are immediate but Control UI is delayed → Gateway/UI event path issue.

Also worth checking duplicate gateway/poller processes:

ps -eo pid,ppid,etime,%cpu,%mem,cmd | grep -E '[o]penclaw|[n]ode'

Docs’ first triage ladder is basically these status/probe/log checks, and Telegram defaults to long polling unless webhook mode is configured. (docs.openclaw.ai)

#OpenClaw is so slow after updating to 2026.4.25