openclaw - 💡(How to fix) Fix [Bug]: 10–15s per-message delay before WebChat/Telegram dispatch to LM Studio on macOS direct install [2 comments, 3 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On OpenClaw 2026.4.26, messages sent through WebChat/UI and Telegram have a consistent 10–15 second delay before OpenClaw appears to start processing them.

CLI commands may have a small normal delay, but they do not show the same repeated 10–15 second per-message delay. The key signal is that LM Studio does not start processing until after the delay, and OpenClaw logs also only appear after the same delay. So this looks like the message is delayed before the model request is dispatched, not like slow model inference.

This may be related to #73421, but my environment is macOS running OpenClaw directly, not Docker/NAS.

Environment

• OpenClaw version: 2026.4.26
• OS: macOS
• Install method: direct/local install, not Docker
• Affected channels/surfaces: WebChat/UI and Telegram
• Not affected: CLI commands
• Model provider: LM Studio / OpenAI-compatible local endpoint
• Model: Gemma4 e4b
• LM Studio version: 0.4.12+1 (0.4.12+1)

Steps to reproduce

1. Run OpenClaw 2026.4.26 directly on macOS.
2. Configure LM Studio as the model provider through the OpenAI-compatible endpoint.
3. Send a message through WebChat/UI.
4. Observe a 10–15 second delay before any OpenClaw logs appear and before LM Studio starts processing.
5. Send a message through Telegram.
6. Observe the same delay.
7. Run a command through the CLI.
8. Observe that CLI commands do not show the same repeated 10–15 second delay.

Expected behavior

Messages sent through WebChat/UI and Telegram should be dispatched to the agent/model promptly, similar to CLI commands. Queued messages should drain continuously once the assistant is ready.

Actual behavior

Messages sent through WebChat/UI and Telegram wait around 10–15 seconds before processing begins.

LM Studio does not receive/start processing the request until after that delay.

OpenClaw logs also appear only after the delay, at the same time LM Studio starts processing.

If multiple messages are queued, the delay happens before each message individually:

lag / waiting at ready → process message + reply → lag / waiting at ready → process message + reply → lag / waiting at ready → process message + reply So it looks like a per-message readiness/queue/channel delay before dispatch, not a model generation delay.

Timing example

• 22:26:13 — pressed send in WebChat
• 22:26:25 — first OpenClaw log appears
• 22:26:25 — LM Studio starts processing
• 22:27:05 — response finishes (normal processing time here)

Why this looks gateway/channel-side

• CLI commands may have a small normal delay, but they do not show the same repeated 10–15 second per-message delay observed through WebChat/UI and Telegram.
• WebChat/UI and Telegram are delayed.
• LM Studio only starts after the delay.
• OpenClaw logs only appear after the delay.
• The delay repeats per queued message.

This suggests the delay is before model dispatch, possibly in the WebChat/UI/Telegram input path, gateway readiness handling, or per-message queue processing.

Related issue

Possibly related to #73421, but that report is for Docker/NAS while this is macOS direct install.

OpenClaw version

2026.4.26

Operating system

macOS 26.1 (25B78)

Install method

Direct/local macOS install, not Docker.

Model

LM Studio local model: Gemma4 e4b

Provider / routing chain

WebChat/UI or Telegram → OpenClaw Gateway → LM Studio OpenAI-compatible endpoint → local model

Additional provider/model setup details

LM Studio is used as an OpenAI-compatible local provider.

The issue does not appear to be LM Studio inference speed because LM Studio does not begin processing until after the 10–15 second delay. OpenClaw logs also appear only after the same delay. CLI commands may have a small normal delay, but they do not show the same repeated 10–15 second per-message delay observed through WebChat/UI and Telegram.

Logs, screenshots, and evidence

Observed behavior:

- WebChat/UI messages wait about 10–15 seconds before OpenClaw logs appear.
- Telegram messages show the same delay.
- LM Studio starts processing only after that delay.
- CLI commands do not show the same repeated 10–15 second delay.
- When multiple messages are queued, the delay repeats before each message:

lag / waiting at ready → process message + reply → lag / waiting at ready → process message + reply

Approx timing example:
- 22:26:13 — pressed send in WebChat
- 22:26:25 — first OpenClaw log appears
- 22:26:25 — LM Studio starts processing
- 22:27:05 — response finishes (normal processing time here)

Additional observation:

Slash/internal commands such as /status and /context return instantaneously.

The delay appears specific to normal message processing through WebChat/UI and Telegram, not all gateway/UI interactions. This further suggests the bottleneck is in the regular message dispatch/agent turn path before the LM Studio request starts, rather than general gateway responsiveness or LM Studio inference.

Impact and severity

Affected users/systems/channels:

• WebChat/UI
• Telegram
• macOS direct OpenClaw install using LM Studio Severity:
• Annoying / workflow-impacting latency. Does not appear to cause data loss from current evidence.

Frequency:

• Appears to happen consistently per queued WebChat/UI or Telegram message.

Consequence:

• Interactive use becomes slow because every message waits ~10–15 seconds before processing starts.
• Queued messages do not drain continuously; each message incurs the delay separately.

Additional information

Possibly related to #73421, but this report is macOS direct install rather than Docker/NAS. First known bad version:

• 2026.4.26

Last known good version:

• 2026.4.24