#OpenClaw huge latency

1 messages · Page 1 of 1 (latest)

dire needle
#

So im a new to openclaw and my experience been very bad since i started, every openclaw command takes many seconds to complete, launching tui takes 30 seconds(5 to get any message after executing the command, more 25 so it lets me type anything), and models are at least 20 seconds slower to even start writing tokens than when testing them in api provider website(example: Gemini or OpenRouter web chat interfaces).

urban peakBOT
#

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

hidden waveBOT
#

Yeah, that’s not normal. A little extra latency vs provider playgrounds is expected because OpenClaw loads agent context/tools/memory, but 30s TUI startup + every CLI command being slow points to local startup/Gateway/env issues.

First, can you paste these?

openclaw --version
which openclaw
node --version
time openclaw --version
time openclaw status
openclaw status --all
openclaw doctor

The status --all report is designed to be shareable/redacted.

Things I’d specifically suspect:

#
  • old/broken install or PATH resolving to a stale openclaw
  • low-power VM/Pi/WSL/filesystem slowness
  • Gateway probe/connect delay
  • shell/Node startup overhead
  • memory/tools/bootstrap work before model calls
  • OpenRouter routing to a slower backend than the provider’s own web UI

Docs for the first triage ladder are here: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/help/troubleshooting

dire needle
hidden waveBOT
#

Nice, this helps a lot.

Good news: your install/Gateway itself looks basically healthy: latest 2026.4.25, gateway reachable in ~60–82ms, service running. The weird part is openclaw status took 1m18 and was mostly CPU time (user 1m15), while openclaw --version took only 0.223s. That means this is probably not “every command startup is slow”; it’s something in status/TUI/session/model runtime diagnostics getting expensive. (pastebin.com)

Do these next:

time openclaw status --json >/tmp/openclaw-status.json
time openclaw security audit >/tmp/openclaw-security.txt
time openclaw gateway status
time openclaw memory status --deep

Also, since doctor archived 10 orphan transcript files, rerun:

# 
time openclaw status

Doctor already cleaned those orphan transcripts, so I want to know if the 1m18 improved after that. (pastebin.com)

For CLI/TUI startup, your host name says “pico”, so if this is a small VM/low-power box, apply the Linux startup tuning from the docs:

grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
mkdir -p /var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1
EOF
source ~/.bashrc
#

Then run time openclaw status twice — first run warms cache, second run is the real comparison. Docs specifically call this out for slow CLI commands on small VMs/ARM hosts. (docs.openclaw.ai)

For model latency: you’re using OpenRouter :free models in the sessions/defaults, so expect queuing/cold-start/routing variance vs the provider’s own chat UI. Check with:

openclaw models status
openclaw models status --probe

Model docs also say fallbacks are the place for cost/latency-sensitive routing, and models status --probe is the live auth/probe check. (docs.openclaw.ai)

dire needle
#

Didnt really improved anything... Should i buy a rtx5090? lol

hidden waveBOT
#

lol no — don’t buy a 5090 for this 😄

A GPU only helps if you’re running local models. It will not fix:

  • OpenRouter/Gemini API first-token latency
  • openclaw status taking 1m+ CPU
  • TUI startup/layout delays

Your paste showed a smoking gun: openclaw --version is fast, but openclaw status burned ~75s of CPU. Let’s isolate whether it’s status rendering/security audit/session table weirdness:

time openclaw status --json >/dev/null
time openclaw status >/dev/null
time env COLUMNS=160 openclaw status >/dev/null
time openclaw security audit >/dev/null

Paste just those timings.