[gateway] ready (8 plugins: acpx, browser, device-pair, memory-core, memory-wiki, phone-control, talk-voice, telegram; 9.6s)
[gateway] starting channels and sidecars...
[ws] res ✗ chat.history 0ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup
[ws] res ✓ node.list 38223ms
[ws] res ✓ device.pair.list 38223ms
[ws] res ✓ models.list 24541ms

tools.effective ~45955ms
doctor.memory.dreamDiary ~17275ms
wiki.importInsights ~17361ms
wiki.palace ~17364ms
doctor.memory.status ~18168ms
sessions.usage ~3500-4000ms
usage.cost ~2000-2700ms
What I already tried:

Disabled trajectory capture with OPENCLAW_TRAJECTORY=0
Disabled model pricing refresh
Reduced/removed old duplicated openclaw.json files
Verified gateway health is fast when idle
Verified the model itself can respond quickly in isolation
I suspect this may be gateway/control-plane event-loop blocking, Control UI eager-loading expensive endpoints, startup sidecar gating, or slow memory/wiki/tools/usage/model endpoints blocking other websocket requests.

### Steps to reproduce

1. Run OpenClaw in Docker/WSL2 with Control UI exposed on `127.0.0.1:18789`.

2. Use a config with several enabled plugins, for example:
   `acpx`, `browser`, `device-pair`, `memory-core`, `memory-wiki`, `phone-control`, `talk-voice`, `telegram`.

3. Start/recreate the gateway container:
   ```bash
   docker compose -f infra/compose.yml up -d --force-recreate clawbot


### Expected behavior

Expected behavior:

Control UI should remain responsive while a chat run is active.
The user message should appear immediately after sending.
Refresh/opening the UI should not block behind a chat run or heavy analytics/control endpoints.
Expensive endpoints like tools/memory/wiki/usage should not block chat/control-plane responsiveness.
Open Control UI at:
http://127.0.0.1:18789

After the UI is loaded and the gateway appears idle, send a very small chat message, for example:
test respond with received

While the message is running, try one or more of the following:

Refresh the Control UI tab.
Open http://127.0.0.1:18789 in another browser/tab.
Watch Docker CPU usage for openclaw-gateway.
Watch gateway websocket logs.
Observe that the UI can stay on loading / fail to update for ~30-45s, and the user message may appear only shortly before the assistant response.

Check that when idle, basic health endpoints are fast:

curl -w "%{time_total}\n" -o /dev/null -s http://127.0.0.1:18789/
curl -w "%{time_total}\n" -o /dev/null -s http://127.0.0.1:18789/healthz
Compare with older v2026.4.14, where the same setup was responsive and the user message appeared immediately.

### Actual behavior

Control UI becomes partially or fully unresponsive during chat runs.

A small test message can take ~30-45s before it appears/responds in the UI. In some cases the user message only becomes visible shortly before the assistant response, which suggests the model response itself is not the only delay.

Refreshing the Control UI during that window can show the loading/connect screen for a long time. Opening the UI in another browser/tab can also be delayed until the chat run is almost finished.

When idle, the gateway is fast:
- `GET /` is usually ~1-5ms
- `GET /healthz` is usually ~1-5ms

During the bad window, `openclaw-gateway` can use around 100% of one CPU core and websocket/control requests appear delayed.

I also saw slow control/diagnostic endpoints in logs, for example:
- `node.list` ~38s during startup-sidecar phase
- `models.list` ~24s
- `tools.effective` ~45s
- memory/wiki diagnostic endpoints ~17-18s
- `sessions.usage` ~3.5-4s
- `usage.cost` ~2-3s

This started after upgrading from `v2026.4.14` to the newer `v2026.4.24 beta/main` line. The same setup was much more responsive before.


### OpenClaw version

v2026.4.26

### Operating system

Windows 11 + WSL2 Ubuntu + Docker Desktop Gateway/container runs in Linux Docker environment, accessed from Windows browser at `http://127.0.0.1:18789`.

### Install method

_No response_

### Model

openai-codex/gpt-5.4 and openai-codex/gpt-5.5  The issue was observed with `gpt-5.4` on low thinking as well, so it does not appear to be specific to `gpt-5.5` or high reasoning.

### Provider / routing chain

Primary provider/model: `openai-codex/gpt-5.4`  Also tested/observed: `openai-codex/gpt-5.5`  Fallbacks configured: - `ollama/qwen3.5:397b-cloud` - `ollama/minimax-m2.7:cloud` - `ollama/gemma4:31b-cloud` - `ollama/qwen3-coder:480b-cloud` - `ollama/qwen3.5:4b`  The slowdown also happens with `openai-codex/gpt-5.4` and low thinking, so it does not seem caused only by fallback routing or `gpt-5.5`.

### Additional provider/model setup details

Model config uses merge mode with OpenAI Codex as primary and Ollama models as fallbacks.

Ollama is configured through:
`http://host.docker.internal:11434`

The configured primary/default model is:
`openai-codex/gpt-5.4`

Subagents are also configured to use:
`openai-codex/gpt-5.4`

Image generation model:
`openai/gpt-image-2`

The issue was reproduced even when the active chat model was `openai-codex/gpt-5.4` with low thinking, so it does not appear to be caused only by a specific model choice or high reasoning mode.

`OPENCLAW_TRAJECTORY=0` was also tested and did not resolve the runtime UI/gateway delay.


### Logs, screenshots, and evidence

```shell
Idle gateway health is fast:


curl -w "%{time_total}\n" -o /dev/null -s http://127.0.0.1:18789/
# ~0.001-0.005s

curl -w "%{time_total}\n" -o /dev/null -s http://127.0.0.1:18789/healthz
# ~0.001-0.005s
Startup / sidecar-related logs:

[gateway] ready (8 plugins: acpx, browser, device-pair, memory-core, memory-wiki, phone-control, talk-voice, telegram; 9.6s)
[gateway] starting channels and sidecars...
[ws] res ✗ chat.history 0ms errorCode=UNAVAILABLE errorMessage=chat.history unavailable during gateway startup
[ws] res ✓ node.list 38223ms
[ws] res ✓ device.pair.list 38223ms
[ws] res ✓ models.list 24541ms
Other slow endpoints observed:

tools.effective ~45955ms
doctor.memory.dreamDiary ~17275ms
wiki.importInsights ~17361ms
wiki.palace ~17364ms
doctor.memory.status ~18168ms
sessions.usage ~3500-4000ms
usage.cost ~2000-2700ms
During the bad window:

Control UI can stay on loading/connect screen.
User message may appear only shortly before the assistant response.
Opening/refreshing Control UI can be delayed.
openclaw-gateway can use around 100% of one CPU core.
After the window ends:

UI becomes responsive again.
/ and /healthz return to ~1-5ms.