openclaw - 💡(How to fix) Fix [Bug]: 10sec latency+before the message send to llm from 2026.2.26 to 2026.4.5 always exist [1 participants]

openclaw2026-04-06 14:58:27

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#61953•Fetched 2026-04-08 03:10:46

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Levis-w

Participants

Levis-w

Timeline (top)

labeled ×2

view the Description

Error Message

# Gateway startup logs showing models.list blocking
18:30:40 gateway ready (7 plugins, 0.9s)
18:30:56 ⇄ res ✓ health 15839ms   # health check triggers catalog load
18:31:14 ⇄ res ✓ models.list 33667ms  # models.list takes 34 seconds!
18:39:16 webchat connected
18:39:30 ⇄ res ✓ chat.send +13710ms  # chat.send waits because catalog still loading

Root Cause

The issue is in the model catalog loading mechanism:

loadGatewayModelCatalog() in model-catalog-CQDWCU0w.js loads the model catalog
It calls augmentModelCatalogWithProviderPlugins() which queries all provider plugins
This process takes 30+ seconds even with only 2 providers configured
The catalog promise is shared, but requests still wait for it to complete
chat.send calls loadGatewayModelCatalog() at line 12740 to resolve thinking level

Key findings from logs:

Health check triggers models.list at startup
Multiple clients receive models.list calls that take 14-34 seconds
chat.send waits for the same catalog promise to resolve

Code Example

# First test after fresh restart: ~1.7 seconds (catalog not yet loaded)
# Subsequent tests: 13-17 seconds (waiting for catalog to load)

---

⇄ res ✓ models.list 33667ms  # 33 seconds for models.list
⇄ res ✓ chat.send 50ms      # chat.send itself is fast

---

# Gateway startup logs showing models.list blocking
18:30:40 gateway ready (7 plugins, 0.9s)
18:30:56 ⇄ res ✓ health 15839ms   # health check triggers catalog load
18:31:14 ⇄ res ✓ models.list 33667ms  # models.list takes 34 seconds!
18:39:16 webchat connected
18:39:30 ⇄ res ✓ chat.send +13710ms  # chat.send waits because catalog still loading

---

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

Summary

view the Description

Steps to reproduce

Bug Description

When models.list RPC is triggered (e.g., by control UI health check or WebSocket client connection), it initiates a model catalog loading process that takes 30+ seconds to complete. During this time, all chat.send requests are blocked and wait for the catalog to finish loading, causing 13-17 second delays in message processing.

Environment

Platform: WSL2 (Windows Subsystem for Linux 2)
OpenClaw Version: Latest (seen in logs)
Node Version: 22.22.0
Model Providers: minimax-portal, custom (deepseek-chat) only (reduced from 11+ providers)
**ver: openclaw 2026.4.5

Steps to Reproduce

Start OpenClaw gateway
Wait for gateway to be ready
Connect a WebSocket client (webchat or control UI)
Send a chat message via chat.send
Observe 13-17 second delay before agent starts processing

Expected Behavior

chat.send should respond within 1-2 seconds under normal conditions. The model catalog loading should not block incoming chat requests.

Actual Behavior

# First test after fresh restart: ~1.7 seconds (catalog not yet loaded)
# Subsequent tests: 13-17 seconds (waiting for catalog to load)

Gateway logs show:

⇄ res ✓ models.list 33667ms  # 33 seconds for models.list
⇄ res ✓ chat.send 50ms      # chat.send itself is fast

The models.list call blocks ALL subsequent requests during its 30+ second execution.

Root Cause Analysis

The issue is in the model catalog loading mechanism:

loadGatewayModelCatalog() in model-catalog-CQDWCU0w.js loads the model catalog
It calls augmentModelCatalogWithProviderPlugins() which queries all provider plugins
This process takes 30+ seconds even with only 2 providers configured
The catalog promise is shared, but requests still wait for it to complete
chat.send calls loadGatewayModelCatalog() at line 12740 to resolve thinking level

Key findings from logs:

Health check triggers models.list at startup
Multiple clients receive models.list calls that take 14-34 seconds
chat.send waits for the same catalog promise to resolve

Impact

User experience severely degraded (13-17 second delay per message)
Blocks all chat functionality when model catalog is being refreshed
Affects all clients connecting to the gateway during catalog load

Logs

# Gateway startup logs showing models.list blocking
18:30:40 gateway ready (7 plugins, 0.9s)
18:30:56 ⇄ res ✓ health 15839ms   # health check triggers catalog load
18:31:14 ⇄ res ✓ models.list 33667ms  # models.list takes 34 seconds!
18:39:16 webchat connected
18:39:30 ⇄ res ✓ chat.send +13710ms  # chat.send waits because catalog still loading

Suggested Fix

Make chat.send not block on models.list completion - cache the thinking level or use a default
Add caching to prevent repeated models.list calls from reloading the catalog
Consider pre-warming the catalog at gateway startup instead of on-demand
Make catalog loading non-blocking for chat requests

Additional Context: This issue persists even after reducing model providers from 11+ to just 2 (minimax-portal and custom/deepseek). The bottleneck is in the catalog loading mechanism itself, not the number of providers.

Expected behavior

100-200ms latency

Actual behavior

10sec or more

OpenClaw version

2026.4.5

Operating system

WSL2 (Windows Subsystem for Linux 2)

Install method

No response

Model

minimax2.7 deepseek chat

Provider / routing chain

openclaw web chat

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Implement a non-blocking catalog loading mechanism to prevent models.list from delaying chat.send requests.

Guidance

Identify the loadGatewayModelCatalog() function in model-catalog-CQDWCU0w.js and modify it to load the catalog in a non-blocking manner, allowing chat.send requests to proceed without waiting for the catalog to finish loading.
Consider implementing caching for the model catalog to prevent repeated models.list calls from reloading the catalog, reducing the delay caused by subsequent requests.
Pre-warming the catalog at gateway startup could also help reduce the delay by loading the catalog before the first chat.send request is received.
Review the augmentModelCatalogWithProviderPlugins() function to optimize its performance, as it is currently taking 30+ seconds to complete even with only 2 providers configured.

Example

// Pseudo-code example of non-blocking catalog loading
async function loadGatewayModelCatalog() {
  // Load catalog in a separate thread or promise
  const catalogPromise = loadCatalogAsync();
  // Allow chat.send requests to proceed without waiting for the catalog
  return catalogPromise;
}

// Load catalog asynchronously
async function loadCatalogAsync() {
  // Load catalog data from providers
  const catalogData = await augmentModelCatalogWithProviderPlugins();
  // Cache the loaded catalog
  cacheCatalog(catalogData);
  return catalogData;
}

Notes

The provided logs and analysis suggest that the bottleneck is in the catalog loading mechanism, and optimizing this process will likely resolve the issue. However, the exact implementation details may vary depending on the specific requirements and constraints of the OpenClaw gateway and model providers.

Recommendation

Apply a workaround by implementing a non-blocking catalog loading mechanism, as this will likely resolve the issue and improve the overall performance of the gateway. This approach allows for a more efficient and scalable solution, reducing the delay caused by catalog loading and improving the user experience.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

100-200ms latency

#permission error #memory optimization #batch processing #GPU compatibility #latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - 💡(How to fix) Fix [Bug]: 10sec latency+before the message send to llm from 2026.2.26 to 2026.4.5 always exist [1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Code Example

Bug type

Beta release blocker

Summary

Steps to reproduce

Bug Description

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Root Cause Analysis

Impact

Logs

Suggested Fix

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING