Bug type

Regression (worked before, now much slower)

Summary

After upgrading from OpenClaw 2026.5.7 to 2026.5.12, overall responsiveness became dramatically worse.

2026.5.7 feels fast and responsive.
2026.5.12 feels extremely slow — not just model responses, but the whole system feels like it gets stuck somewhere in the command / gateway / channel path.

The subjective difference is huge:

• 2026.5.7 feels like a plane
• 2026.5.12 feels like a bicycle

This is not a minor slowdown. It is large enough to affect normal usage.

Steps to reproduce

1. Use OpenClaw with QQBot enabled
2. Compare OpenClaw 2026.5.7 and 2026.5.12 on the same machine / same environment
3. Run normal chat interactions and basic commands like:
   • openclaw status
   • model calls
   • normal inbound message handling
4. Observe response latency and general responsiveness

Expected behavior

2026.5.12 should have similar or better responsiveness than 2026.5.7.

Actual behavior

2026.5.12 is much slower than 2026.5.7.

The slowdown is not limited to one model. It feels like the system stalls somewhere in a higher-level command / gateway / channel phase.

OpenClaw version

• Slow version: 2026.5.12
• Fast version: 2026.5.7

Operating system

Linux (Ubuntu/Debian-based)

Install method

npm global install

Model

Tested with multiple models, including:

• lau_api/gpt-5.4
• tencentcodingplan/glm-5

This does not appear to be only a single-model provider issue.

Provider / routing chain

OpenClaw -> external model providers / QQBot channel

Measured evidence

On 2026.5.12

• openclaw status: about 7.7s
• gpt-5.4 simple one-word reply: about 9.3s
• glm-5 simple one-word reply: about 8.5s

On 2026.5.7

• openclaw status: about 6.4s
• gpt-5.4 simple one-word reply: about 7.2s
• glm-5 simple one-word reply: about 10.0s (variable)

Important command-path observation

Some low-level commands are fast:

• node -e "console.log('ok')": ~0.02s
• openclaw --help: ~0.07s
• openclaw gateway status: ~1.38s

But:

• openclaw status: ~11.3s in one test

This suggests the slowdown is not simple Node startup overhead. It looks more like a slowdown inside a higher-level aggregated command path.

Logs / evidence

I observed liveness warnings like this:

[diagnostic] liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=214.6 eventLoopDelayMaxMs=5767.2 eventLoopUtilization=0.465 cpuCoreRatio=0.571 active=1 waiting=0 queued=1 phase=channels.qqbot.start-account recentPhases=sidecars.restart-sentinel:0ms,sidecars.subagent-recovery:4ms,sidecars.main-session-recovery:2ms,post-attach.update-sentinel:0ms,sidecars.session-locks:29ms,post-ready.maintenance:142ms work=[active=agent:main:qqbot:direct:... queued=agent:main:qqbot:direct:...]

This seems especially suspicious:

• eventLoopDelayMaxMs=5767.2
• phase=channels.qqbot.start-account

That looks like the gateway event loop is being blocked during QQBot startup / account-start phases, which may explain why the whole system becomes sluggish.

Additional observations

• The issue feels broader than just one model being slow.
• It affects the overall responsiveness of the system.
• The slowdown feels like something is “stuck in a command path” rather than only the model backend being slow.
• There may be a relation to channel startup, diagnostics, or QQBot-related phases.

Impact and severity

High.

This is a major usability regression. The difference between 2026.5.7 and 2026.5.12 is immediately noticeable in daily use.

Additional information

I also found other GitHub issues that may be related:

• [Bug]: All model requests timed out #82021 (All model requests timed out)
• Telegram/QQBot plugins fail to connect on servers without global IPv6 (undici IPv6-first issue) #75539 (Telegram/QQBot plugins fail to connect on servers without global IPv6)