A slow OpenClaw reply can come from model inference, a long conversation, a tool call, or the computer running the Gateway. Diagnose the delay before changing concurrency or buying a larger server.
Independent guide. Diagnostic and hosting references checked on October 2, 2026. This page provides a measurement workflow, not published latency or concurrency benchmarks.
Establish a repeatable baseline
Record the installed version, selected model, host, and a small task you can repeat. Compare a short text-only request with the task that feels slow. Keep the model and account the same while making that comparison.
openclaw --version
openclaw gateway status
openclaw gateway health
openclaw doctor
If the Gateway is unhealthy, resolve that before interpreting the delay as model performance. Use the Gateway query reference and troubleshooting guide to understand the reported failure.
Separate the stages of the delay
| Observation | What to investigate |
|---|---|
| Dashboard itself is slow or disconnects | Gateway health, host pressure, network or remote-access path |
| Plain text is slow in a fresh conversation | Model endpoint, provider load, account limits, network |
| One long conversation is slower | Context size and session handling |
| Text works, browsing or file task is slow | The particular tool, target website, or filesystem |
| Slow only under simultaneous work | Resource use, configured concurrency, provider limits |
Watch the relevant logs while reproducing one task:
openclaw logs --follow
Write down which action was waiting rather than relying on a single total response time. Redact task content before sharing diagnostic output.
Check model latency and task scope
A larger or slower model can dominate the total time even when the Gateway host is mostly idle. Compare candidate models with the same short prompt and then the representative task. Judge both quality and delay; a faster response that misses the task is not a useful optimization.
Use the official model CLI reference to inspect and select the models supported by your setup. Confirm account access and provider usage before switching. This guide does not promise a particular model's current price or speed.
Reduce unnecessary repeated work in the task instructions. For example, ask for a bounded number of sources and a clear stopping point in a research task. Observe whether extra tool calls or retries explain the cost and latency before changing host settings.
Compare a fresh conversation
Repeat the same small task in a new conversation and compare it with the long session. A difference is useful evidence to investigate context and session behavior; it does not prove a memory leak.
Follow official compaction guidance and the session reference for the installed version. Do not replace state storage or delete history as a generic speed fix. Back up first if a recovery step changes state.
Inspect the host under the real workload
On a Linux VPS, observe CPU, available memory, disk capacity, and any out-of-memory events while the task runs. On a local computer, use its system monitor. For Docker, the standard container resource view is:
docker stats
An image build and an ordinary chat session have different resource needs. The official Docker documentation currently calls for at least 6 GB RAM for a local source build; a pre-built image avoids that build requirement.
Do not add PM2 cluster mode, Redis, BullMQ, PostgreSQL, or PgBouncer solely because a generic web-application tuning article mentions them. Those services were not a documented requirement for the OpenClaw installation covered by the earlier version of this page, and its made-up SQL schemas and load-test endpoints have been removed.
Use the VPS selection guide if measurement shows the host is the bottleneck.
Treat concurrency as a measured setting
Inspect the supported schema before changing any limit:
openclaw config schema
openclaw config validate
More simultaneous work can increase contention or hit provider limits. Change one supported setting, repeat the same representative workload, and record the outcome. Restore the previous value if quality or responsiveness worsens.
No session-per-core or guaranteed throughput claim is provided here. Meaningful capacity results need the model, task mix, tools, host specification, and software version recorded together.
Slow CLI startup on a small Linux host
The official Linux server guide documents Node's module compile cache for repeated command startup. It improves that specific stage; it should not be described as a fix for provider inference time.
Use that guidance only if command startup is the measured issue, and place service settings through the documented service-manager mechanism. Changing a shell environment does not automatically update an existing managed service.
Verify one change at a time
Before changing a working installation, preserve the current config and a backup. After the change, validate config, check Gateway health, and repeat the baseline task. Keep observations on response completeness, tool outcomes, delay, and model spending.
If the change needs a restart, check active work first and use the managed lifecycle documented in our CLI guide. The configuration guide explains safe edits.
FAQ
Will a larger VPS make every reply faster?
Only if the VPS is limiting the workload. A remote model or slow external tool can still dominate the delay.
Does growing memory use prove a leak?
No. Task activity, browser processes, caches, and context can change resource use. Compare repeatable workloads and collect relevant diagnostics before making that diagnosis.
Which optimization should I try first?
Resolve the earliest measured bottleneck: Gateway health, provider latency, tool work, conversation context, or host pressure. See OpenClaw not working if the task is failing rather than merely slow.