**Bug: Gateway pegs CPU at 100%+ on ARM64 (Raspberry Pi 5)**

[weary sparrow]

Bug: Gateway pegs CPU at 100%+ on ARM64 (Raspberry Pi 5)

Platform: Raspberry Pi 5 (8GB) — ARM64
OS: Ubuntu Desktop 25.10
OpenClaw version: [2026.4.26]

Description:
The gateway process consistently pegs CPU at 100%+ on ARM64 architecture. This causes two main issues:

• The TUI becomes completely unusable (frozen/unresponsive)
• Bot responses are significantly slower than expected

What's working:

• Gateway starts and runs
• Discord connection is stable
• Jobs/automation run fine
• Bot responds to messages (just very slowly)

What's broken:

• TUI is unusable due to CPU load
• Response latency is much higher than on x86

Workarounds tried:

• Clean reinstall
• Disabled Bonjour/mDNS (discovery.mdns.mode=off)
• Set timeoutSeconds=120 for model provider
• Set Restart=no in systemd to prevent duplicate processes

None of these resolved the CPU issue — they addressed other problems but the ARM64 CPU bug persists.

Suspected cause: Something in the gateway process doesn't behave well on ARM64 — possibly a busy loop or polling interval issue.

Happy to provide logs or test any fixes.

[sharp kiln]

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

[brittle plover]

This looks like a real ARM64 gateway bug, not a model timeout or mDNS issue. I found older ARM64/high-CPU plugin-runtime reports, but your case is newer (2026.4.26) and different because the gateway does run, Discord stays connected, and CPU remains pegged. Worth filing as a fresh GitHub issue, or adding to an existing one if maintainers point you there. (github.com)

Please include these in the issue:

openclaw --version
node --version
npm --version
uname -a
lsb_release -a
openclaw status --all
openclaw gateway status --deep
journalctl --user -u openclaw-gateway.service --no-pager -n 300

And while CPU is pegged:

PID=$(pgrep -f 'openclaw.*gateway' | head -n1)
ps -p "$PID" -o pid,ppid,etime,%cpu,%mem,rss,vsz,args
top -b -H -n 1 -p "$PID" | head -60

A few useful details to answer in the issue:

• Does CPU peg immediately after gateway start, or only after the first Discord message/job?
• Is the hot process the daemon service, the interactive openclaw gateway TUI, or both?
• Node 22 vs Node 24?
• SD card vs USB SSD?
• Any plugins/channels enabled besides Discord?

Docs say a Pi 5 should be fine as a gateway, and recommend 64-bit Pi OS Lite, Node 24, USB SSD, and throttling checks — so a single gateway process sitting at 100%+ is not expected behavior. (docs.openclaw.ai)

Short-term: keep running headless/daemon-only if the TUI is unusable, and don’t chase timeoutSeconds further — that affects model calls, not idle gateway CPU. Also mention your Restart=no workaround in the issue; it’s useful context, but I’d treat it as diagnostic-only rather than the final service setup.