Environment

• OS: Windows
• Channel: Feishu DM
• OpenClaw: 2026.5.2
• Gateway runtime symptom: Runtime: unknown
• Gateway process memory observed locally:
  • WS: ~419MB
  • PM: ~594MB
• Model: ruled out locally as the primary cause

Summary
After upgrading to 2026.5.2, Feishu DM replies became much slower on Windows.
The delay does not appear to be in Feishu ingress itself. Logs show the slowdown happens mainly between:

• dispatching to agent
• dispatch complete

So the latency appears in the agent/session/context processing stage.

In this environment, reply latency increased significantly, commonly to 30–60s, and sometimes subjectively feels like 80s+.

Local evidence

1. Feishu ingress is fast
   Gateway logs show the message is received and dispatched immediately.

Example:

• received: 20:41:55
• dispatching to agent: 20:41:55
• dispatch complete: 20:42:01

This short case is ~6s.

But many other cases are much slower:

• 12:04:03 -> 12:04:37 = ~34s
• 12:16:31 -> 12:17:23 = ~52s
• 12:19:05 -> 12:19:46 = ~41s
• 12:21:44 -> 12:22:47 = ~63s
• 12:23:03 -> 12:23:59 = ~56s

2. Current Feishu session is very large
   Session files:

• session jsonl: 357,286 bytes
• trajectory jsonl: 231,704 bytes

Trajectory stats:

• 228,019 characters
• 11,483 words

3. Session token usage is abnormally high
   From session metadata:

• inputTokens: 185677
• inputTokens: 205052

This strongly suggests the session/context has become very heavy.

4. Injected context appears large
   The session content includes:

• large skills catalog
• many tool schemas
• system/context injection blocks

This may be much more expensive in 2026.5.2 when the session grows.

Current assessment
This does not look like:

• Feishu transport slowness
• model slowness
• gateway not receiving messages

It looks more like:
On Windows + Feishu DM, long-lived session reuse in 2026.5.2 leads to very large session/trajectory/context size, which significantly increases agent processing latency.

Additional symptom
openclaw gateway status shows:

• Runtime: unknown
• but also RPC probe: ok

So the service is alive, but there may also be a Windows-specific runtime/service-state regression around the same version.

Expected behavior
Even with long-lived Feishu DM sessions, reply latency should not degrade this sharply after upgrade.
Session/context growth should either:

• be bounded,
• be summarized,
• or not cause large per-turn latency regression.

Areas to investigate

1. Whether 2026.5.2 changed session/context injection cost
2. Whether large trajectory/session files now impact per-turn latency more heavily
3. Whether Windows Runtime: unknown is related to this regression
4. Whether Feishu DM long-lived sessions need automatic compaction/summarization