openclaw - 💡(How to fix) Fix Telegram direct chat replies spend ~25–31s in embedded agent startup/prep before streaming [3 comments, 4 participants]

Summary

Telegram direct-chat replies are consistently slow because every normal message appears to pay ~25–31s of embedded agent startup/prep overhead before model streaming begins. This happens even for trivial messages like ping → pong.

This looks like a runtime/performance issue rather than model generation latency: the trace shows most time is spent in model-resolution, auth, core-plugin-tools, system-prompt, and stream-setup before the assistant can start replying.

Environment

• OpenClaw: 2026.4.29 (a448042)
• OS: macOS 26.3.1 arm64
• Gateway runtime: Node 22.22.1
• CLI Node observed by openclaw status: Node 25.8.0
• Gateway mode: local loopback LaunchAgent
• Channel: Telegram direct chat
• Model: openai-codex/gpt-5.5
• Session context at time of testing: ~80k / 272k tokens (~30%)

What I tried

I reduced the runtime/config surface to rule out obvious local configuration overhead:

• Restricted plugins to only openai and telegram
• Enabled fast mode for the main agent / model config
• Disabled heartbeat system-prompt section injection
• Set main agent skillsLimits.maxSkillsPromptChars = 0
• Reduced main agent context limits
• Restarted the Gateway
• Confirmed Telegram messages were received and replied to

Even after these changes, each simple direct chat message still spent roughly 25–31s in startup/prep.

Representative trace samples

Sample 1

startup totalMs=12616
  workspace:0ms
  runtime-plugins:1ms
  hooks:1ms
  model-resolution:6785ms
  auth:3330ms
  context-engine:1ms
  attempt-dispatch:2498ms

prep totalMs=16492
  workspace-sandbox:4ms
  skills:0ms
  core-plugin-tools:6281ms
  bootstrap-context:267ms
  bundle-tools:984ms
  system-prompt:3718ms
  session-resource-loader:959ms
  agent-session:2ms
  stream-setup:4277ms

Total before stream-ready: ~29.1s.

Sample 2

startup totalMs=12849
  model-resolution:6916ms
  auth:3353ms
  attempt-dispatch:2578ms

prep totalMs=16636
  core-plugin-tools:6604ms
  bundle-tools:986ms
  system-prompt:3683ms
  session-resource-loader:993ms
  stream-setup:4351ms

Total before stream-ready: ~29.5s.

Sample 3

startup totalMs=11430
  model-resolution:6175ms
  auth:3008ms
  attempt-dispatch:2246ms

prep totalMs=13794
  core-plugin-tools:5125ms
  bundle-tools:839ms
  system-prompt:3084ms
  session-resource-loader:926ms
  stream-setup:3813ms

Total before stream-ready: ~25.2s.

Sample 4

startup totalMs=15625
  model-resolution:8736ms
  auth:4321ms
  attempt-dispatch:2567ms

prep totalMs=15681
  core-plugin-tools:5473ms
  bundle-tools:892ms
  system-prompt:4301ms
  session-resource-loader:902ms
  stream-setup:4104ms

Total before stream-ready: ~31.3s.

Current interpretation

The main cost appears to be fixed per-turn embedded agent preparation, not the Telegram API or the LLM generating the response.

Likely optimization areas:

• Cache model resolution across turns
• Cache auth/profile resolution across turns
• Cache tool inventory / plugin tool preparation
• Cache or incrementally build system prompts
• Avoid full embedded agent prep for trivial/direct chat messages
• Provide a lightweight reply path for normal chat messages
• Keep the runner/session warm between turns

Notes

There was separate Telegram/TUN network instability earlier in the setup, but after the Telegram channel became usable, the per-turn embedded agent trace still consistently showed ~25–31s before stream-ready. So the trace above appears to be a separate runtime overhead issue.