Huge lag between pressing send in the webchat and LM Studio starting to process (OpenClaw 2026.4.26) | Friends of the Crustacean 🦞🤝 | Page 1

mossy lintel Apr 29, 2026, 4:56 PM

#

Affects webchat as well as telegram. Takes a good 10-15 seconds for LM Studio to start processing. Even openclaw logs show up after 10-15 seconds (at the same time as when LM Studio starts processing)

quasi ibexBOT Apr 29, 2026, 4:56 PM

#

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

outer jungle Apr 29, 2026, 4:56 PM

#

This is an issue in OpenClaw 2026.4.26

charred gateBOT Apr 29, 2026, 4:57 PM

#

The important clue is: OpenClaw logs don’t appear until the same 10–15s delay. That means LM Studio probably isn’t the first bottleneck — the message is likely delayed before the model request starts, somewhere in gateway/session/channel handling.

Since the title says 2026.4.26, first please confirm with:

openclaw --version
openclaw doctor
openclaw gateway status

Then I’d try:

openclaw gateway restart

If it still happens, please grab logs around one send attempt with timestamps. What we need to know is whether there’s a gap between:

#

pressing send in WebChat/Telegram
OpenClaw receiving/dispatching the inbound message
OpenClaw calling LM Studio
LM Studio receiving the request

Because this affects both WebChat and Telegram, it’s probably not Telegram-specific. If the gateway is just silently sitting for 10–15s before any inbound log, this may be a 2026.4.26 regression and would be worth filing with repro details here: https://github.com/openclaw/openclaw/issues

Troubleshooting docs: https://docs.openclaw.ai/gateway/troubleshooting

#

Yep — given it hits WebChat + Telegram and OpenClaw doesn’t log until the delay ends, I’d treat this as a 2026.4.26 gateway-side regression, not an LM Studio issue.

Worth collecting for the GitHub issue:

openclaw --version
openclaw doctor
openclaw logs --follow

Then send one WebChat message and note exact timestamps for:

press send
first OpenClaw log line
LM Studio starts processing

If they’re all delayed together, that’s strong evidence the delay is before model dispatch. 2026.4.26 included Gateway/startup, WebChat handshake, plugin/runtime, and local-model changes, so a regression there is plausible. (github.com)

#

If they’re blocked, I’d test whether the lag disappears on the last known-good version they had installed, then file it with that comparison: https://github.com/openclaw/openclaw/issues

mossy lintel Apr 29, 2026, 4:58 PM

#

outer jungle This is an issue in OpenClaw 2026.4.26

Is it? Had this been reported on the github?

charred gateBOT Apr 29, 2026, 4:59 PM

#

I checked — a very similar 2026.4.26 regression is already on GitHub, but I don’t see one that exactly says “WebChat + Telegram + LM Studio starts 10–15s late.”

Closest match is #73421: upgrade 2026.4.23 → 2026.4.26, delayed reply delivery, WebChat/control-ui websocket stalls, and internal requests like node.list taking tens of seconds. That sounds very relevant. (github.com)

There’s also #72338 for Telegram reply stalls/gateway CPU spin, and #74353 for LM Studio timeout/cold-load behavior, but those seem less exact. (github.com)

I’d either add your WebChat+Telegram+LM Studio timing evidence to #73421, or file a new issue and reference it if your logs show a different pattern.

GitHub

Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

GitHub

Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

mossy lintel Apr 29, 2026, 5:00 PM

#

charred gate Yep — given it hits **WebChat + Telegram** and OpenClaw doesn’t log until the de...

commands are not delayed when run through CLI.. theres a lag only when its sent through webchat or UI.

if multiple messages are queued, the lag is there for each of them.
lag -> process message & reply -> lag (waiting at ready) -> process message & reply -> lag (waiting at ready) -> process message & reply.....

so on

charred gateBOT Apr 29, 2026, 5:01 PM

#

That extra detail is important — it makes “LM Studio slow/cold-loading” much less likely.

If CLI commands are immediate, but WebChat/UI queued messages each wait 10–15s before processing, that points to a per-message gateway/control-plane readiness or queue delay before the agent/model call starts.

I’d add exactly this to #73421:

CLI path has no delay
WebChat/UI path has delay
queued messages don’t drain continuously
each message waits again at “ready” before processing
LM Studio receives the request only after that wait

That “lag → process → lag → process” pattern is strong evidence of a fixed timeout/gate being hit per turn, not model inference. If your environment isn’t NAS/Docker like #73421, I’d file a separate issue and reference #73421 rather than burying it.

mossy lintel Apr 29, 2026, 5:02 PM

#

could you tell me what to add?

charred gateBOT Apr 29, 2026, 5:02 PM

#

Yep — I’d add this as a comment to #73421:

https://github.com/openclaw/openclaw/issues/73421

Copy/paste draft:

I’m seeing a similar delay on OpenClaw 2026.4.26, but with an important distinction:

- CLI commands are not delayed.
- The delay only happens when messages are sent through WebChat/UI and Telegram.
- LM Studio does not receive/start processing the request until after the delay.
- OpenClaw logs also only appear after the same 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 → ...

#


This makes it look less like LM Studio model inference/cold load and more like a per-message gateway/WebChat/UI/channel readiness or queue delay before the model request is dispatched.

Approx timing:
- Delay before first log/model request: about 10–15 seconds per message
- Affected paths: WebChat/UI + Telegram
- Not affected: CLI

Environment:
- OpenClaw version: 2026.4.26
- OS/install method: TODO
- Model provider: LM Studio / OpenAI-compatible endpoint
- Model: TODO

I can provide logs/timestamps if useful.

#

If you can, fill in the TODOs and add a tiny timestamp sample like:

17:04:10 pressed send in WebChat
17:04:24 first OpenClaw log appears
17:04:24 LM Studio starts processing

That’s the useful bit. It shows the lag is before dispatch, not model generation.

mossy lintel Apr 29, 2026, 5:04 PM

#

also, im runningg openclaw directly on mac not docker

charred gateBOT Apr 29, 2026, 5:04 PM

#

That’s worth adding — it makes your report more useful because #73421 was NAS/Docker-specific.

Use this updated environment bit:

Environment:
- OpenClaw version: 2026.4.26
- OS/install method: macOS, running OpenClaw directly / not Docker
- Model provider: LM Studio / OpenAI-compatible endpoint
- Model: TODO

And I’d add one extra sentence near the top:

This is happening on macOS with OpenClaw running directly, not in Docker/NAS, so it may be broader than the NAS Docker environment reported in this issue.

#

So yes: comment on #73421 if you want to connect it, but because your environment is macOS direct install, a new issue referencing #73421 would also be totally reasonable.

mossy lintel Apr 29, 2026, 5:04 PM

#

ok. give me full

charred gateBOT Apr 29, 2026, 5:04 PM

#

I’d file a new issue since yours is macOS direct install, then reference #73421.

Issue link: https://github.com/openclaw/openclaw/issues/new

Copy/paste:

### Bug type

Regression / performance issue

### 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.

This does not happen when using CLI commands.

#


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 endpoint
- Model: TODO
- LM Studio version: TODO, if known

#


### 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 are not delayed.

### 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

TODO, replace with real timestamps if possible:

- 17:04:10 — pressed send in WebChat
- 17:04:24 — first OpenClaw log appears
- 17:04:24 — LM Studio starts processing
- 17:04:XX — response finishes

### Why this looks gateway/channel-side

- CLI commands are not delayed.
- 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.

If you can add a short openclaw doctor output and one timestamp sample, that’ll make it much easier for maintainers to chase.

mossy lintel Apr 29, 2026, 5:05 PM

#

give me title

charred gateBOT Apr 29, 2026, 5:05 PM

#

Use:

[Bug]: 10–15s per-message delay before WebChat/Telegram dispatch to LM Studio on macOS direct install

mossy lintel Apr 29, 2026, 5:10 PM

#

give me these details

OpenClaw version
*
Exact version/build tested.

Operating system
*
OS and version where this occurs.

Install method
How OpenClaw was installed or launched.

Model
*
Effective model under test.

Provider / routing chain
*
Effective request path through gateways, proxies, providers, or model routers.

Additional provider/model setup details
Optional. Include redacted routing details, per-agent overrides, auth-profile interactions, env/config context, or anything else needed to explain the effective provider/model setup. Do not include API keys, tokens, or passwords.
Markdown Editor
Markdown input: edit mode selected.
Write
Preview

Logs, screenshots, and evidence
Include the redacted logs, screenshots, recordings, docs, or version comparisons that support the grounded answers above.

Impact and severity
Explain who is affected, how severe it is, how often it happens, and the practical consequence using only observed evidence. If any part cannot be grounded from the evidence, respond with exactly NOT_ENOUGH_INFO. Include:

Affected users/systems/channels
Severity (annoying, blocks workflow, data risk, etc.)
Frequency (always/intermittent/edge case)
Consequence (missed messages, failed onboarding, extra cost, etc.)
Markdown Editor
Markdown input: edit mode selected.
Write
Preview

Additional information
Add any remaining grounded context that helps triage but does not fit above. If this is a regression, include the last known good and first known bad versions when observed. If there is not enough evidence, respond with exactly NOT_ENOUGH_INFO.
Markdown Editor
Markdown input: edit mode selected.
Write
Preview

Metadata
Assignees
No one assigned
Labels
bug
Something isn't working
Type
No type
Projects
No projects
Milestone
No milestone
Remember, contributions to this repository should follow its contributing guidelines and security policy.

charred gateBOT Apr 29, 2026, 5:10 PM

#

Use these — replace the TODOs if you know them:

OpenClaw version

2026.4.26

Operating system

macOS TODO_VERSION

Install method

Direct/local macOS install, not Docker.

#

Model

LM Studio local model: TODO_MODEL_NAME

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 are not delayed.

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 are not delayed.
- 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:

TODO:
- HH:MM:SS — pressed send in WebChat
- HH:MM:SS — first OpenClaw log appears
- HH:MM:SS — LM Studio starts processing

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:
- NOT_ENOUGH_INFO

mossy lintel Apr 29, 2026, 5:14 PM

#

check

https://ctxt.io/2/AAD4yxxeFg

charred gateBOT Apr 29, 2026, 5:14 PM

#

I checked — that paste is the stricter GitHub issue template, so use grounded wording and NOT_ENOUGH_INFO where you don’t know exact values. (ctxt.io)

Title:
[Bug]: 10–15s per-message delay before WebChat/Telegram dispatch to LM Studio on macOS

Bug type:
Regression / Performance

Beta release blocker:
No

Summary:
On OpenClaw 2026.4.26, WebChat/UI and Telegram messages wait about 10–15 seconds before OpenClaw logs appear and before LM Studio starts processing, while CLI commands are not delayed.

Steps to reproduce:

#

1. Run OpenClaw 2026.4.26 directly on macOS.
2. Use LM Studio through an OpenAI-compatible endpoint.
3. Send a message through WebChat/UI.
4. Observe a 10–15 second delay before 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 CLI.
8. Observe that CLI commands are not delayed.

Expected behavior:
WebChat/UI and Telegram messages should begin processing promptly, comparable to the observed CLI path, without a 10–15 second per-message wait before logs/model dispatch.

Actual behavior:
WebChat/UI and Telegram messages wait about 10–15 seconds before OpenClaw logs appear and before LM Studio starts processing.

#

If multiple messages are queued, each message incurs the delay separately:

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

OpenClaw version:
2026.4.26

Operating system:
macOS exact version: NOT_ENOUGH_INFO

Install method:
Direct/local macOS install, not Docker.

Model:
LM Studio local model. Exact model name: NOT_ENOUGH_INFO

#


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 through an OpenAI-compatible local endpoint.

The delay appears before LM Studio receives/starts processing the request. OpenClaw logs also appear only after the same delay. CLI commands are not delayed.

Logs, screenshots, and evidence:
Observed evidence:

- 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 are not delayed.
- Queued messages do not drain continuously; each message waits again before processing.

Timing sample:
NOT_ENOUGH_INFO

Impact and severity:
Affected users/systems/channels:
- WebChat/UI
- Telegram
- macOS direct OpenClaw install using LM Studio

Severity:
- Annoying / workflow-impacting latency.

#

Frequency:
- Observed per WebChat/UI or Telegram message, including queued messages.

Consequence:
- Interactive use becomes slow because each message waits about 10–15 seconds before processing begins.
- Queued messages take much longer because the delay repeats per message.

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:
NOT_ENOUGH_INFO

mossy lintel Apr 29, 2026, 5:16 PM

#

any other issues on github mentioning similar behavior?

charred gateBOT Apr 29, 2026, 5:18 PM

#

Yes — I found a few related ones, but none that exactly match macOS direct install + WebChat/Telegram + LM Studio + 10–15s before dispatch.

I’d add this to your issue:

Related issues / similar symptoms:

- #73421 — 2026.4.26 regression with delayed reply delivery, WebChat/control-ui websocket stalls, `node.list` taking tens of seconds, and outbound delivery delays. Closest match, but reported on NAS/Docker.
- #72338 — Gateway CPU spin where Telegram messages are received but assistant replies stall, and local status probes time out.
- #73532 — Plugin loader hot loop / event-loop starvation; reports WS RPC timeouts and Telegram updates not being drained.
- #73581 — Agent processing lane can stay stuck in `processing` with `queueDepth=1`, preventing new messages from being processed.
- #74353 — LM Studio-related 2026.4.26 issue, but focused on cold-load / timeoutSeconds behavior rather than WebChat/Telegram dispatch delay.

This issue seems distinct because CLI commands are not delayed, while WebChat/UI and Telegram each incur a repeated 10–15s delay before LM Studio even starts processing.

The strongest ones to reference are #73421, #72338, #73532, and #73581. #74353 is LM Studio-related, but less directly about your queue/dispatch lag. (github.com)

GitHub

Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

mossy lintel Apr 29, 2026, 5:23 PM

#

there is a slight lag in CLI... but the regular type I think

charred gateBOT Apr 29, 2026, 5:23 PM

#

Got it — then phrase it a bit softer so the issue doesn’t overclaim:

CLI commands may have a small normal startup/dispatch delay, but they do not show the same repeated 10–15 second per-message delay observed through WebChat/UI and Telegram.

And update the evidence bullets to:

- WebChat/UI and Telegram show a repeated ~10–15 second delay before OpenClaw logs appear and before LM Studio starts processing.
- CLI may have a small normal delay, but not the same repeated 10–15 second delay.
- The WebChat/UI + Telegram delay repeats for each queued message.

That’s more accurate and still preserves the key distinction.

mossy lintel Apr 29, 2026, 5:25 PM

#

I have posted

https://github.com/openclaw/openclaw/issues/74491

charred gateBOT Apr 29, 2026, 5:25 PM

#

Nice, it’s up: https://github.com/openclaw/openclaw/issues/74491

I checked it — the important facts are there. Two tiny improvements if you want to polish it:

Remove/fix the duplicated headings like ### Summary / ### Steps to reproduce appearing twice.
Replace the remaining TODOs if you can:
- exact macOS version
- exact LM Studio model
- LM Studio version

But honestly, it’s already useful: it’s labeled bug + regression, links the macOS/direct-install angle, and captures the key “delay before logs + before LM Studio dispatch” signal.

mossy lintel Apr 29, 2026, 5:28 PM

#

done check

charred gateBOT Apr 29, 2026, 5:29 PM

#

Checked — it looks solid now. The key evidence + timing sample are in there. 👍

Only 3 tiny edits I’d still make:

Remove duplicate headings
- ### Expected behavior appears twice
- ### Actual behavior appears twice
Soften the CLI wording since you said there is slight normal CLI lag:

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.

Double-check this line

Model provider: LM Studio/ Google

#

If you mean LM Studio serving Gemma locally, I’d change it to:

Model provider: LM Studio / OpenAI-compatible local endpoint

Otherwise it’s good. The timing sample is especially useful.

mossy lintel Apr 29, 2026, 5:33 PM

#

check'

charred gateBOT Apr 29, 2026, 5:34 PM

#

Checked — much better now. Provider line is fixed, duplicate headings are gone, and the CLI wording is softened in the later sections.

One remaining minor inconsistency: near the top it still says:

This does not happen when using CLI commands.

I’d change that to:

CLI commands may have a small normal delay, but they do not show the same repeated 10–15 second per-message delay.

Also in logs/evidence it still says:

#

- CLI commands are not delayed.

Change to:

- CLI commands do not show the same repeated 10–15 second delay.

After that, I’d call it good.

mossy lintel Apr 29, 2026, 5:35 PM

#

done check

charred gateBOT Apr 29, 2026, 5:35 PM

#

Yep — checked. It looks good now. The wording is consistent, the provider line is fixed, and the CLI caveat is handled properly.

Only tiny nit left: in Steps to reproduce, step 8 still says:

Observe that CLI commands are not delayed.

If you want it perfectly consistent, change that to:

Observe that CLI commands do not show the same repeated 10–15 second delay.

But honestly, the issue is solid as-is. Happy to help! 🦐

mossy lintel Apr 29, 2026, 5:40 PM

#

done check

charred gateBOT Apr 29, 2026, 5:40 PM

#

Yep — checked. This is good now. The CLI wording is consistent in the summary, repro steps, and evidence section.

One minor thing: the GitHub API view I can see is truncated right at ### Addition..., but everything before that is clean and useful. I’d stop editing unless someone asks for more detail.

Good bug report. 🦐

mossy lintel Apr 29, 2026, 5:40 PM

#

also one thing to note... commands like /status, /context etc return instantaneously

charred gateBOT Apr 29, 2026, 5:40 PM

#

That’s a very useful clue — add a short comment to the issue:

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.

That helps narrow it a lot.

mossy lintel Apr 29, 2026, 5:42 PM

#

done

charred gateBOT Apr 29, 2026, 5:42 PM

#

I checked the comments — I don’t see your new /status / /context note showing up yet, at least not via the GitHub API. It may not have saved, or GitHub may be lagging.

The bot did already leave a useful triage comment saying maintainers should trace:

WebChat send click
chat.send ACK
dispatchInboundMessage
agent run start
first LM Studio HTTP request
equivalent Telegram timestamps

So your instant /status / /context observation fits really well. If it didn’t post, add this:

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.

mossy lintel Apr 29, 2026, 5:43 PM

#

its up

charred gateBOT Apr 29, 2026, 5:44 PM

#

Yep, confirmed — it’s in the issue body now under Logs, screenshots, and evidence:

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

That’s a strong extra clue. I’d leave it there and stop touching the issue unless maintainers ask for a trace/log.

mossy lintel Apr 29, 2026, 5:45 PM

#

thanks

#Huge lag between pressing send in the webchat and LM Studio starting to process (OpenClaw 2026.4.26)