openclaw - 💡(How to fix) Fix Measure and reduce OpenClaw-owned pre-model latency in channel replies

Summary

In a Slack-agent run on OpenClaw 2026.5.28, the observed end-to-end reply lifecycle was about 5.0s, while the actual provider/model call span was about 2.8s. The remaining time is OpenClaw-owned overhead around dispatch, harness execution, context/input preparation, and reply delivery.

The largest unexplained gap in the observed trace data was between openclaw.harness.run starting and openclaw.model.call starting: approximately 1.3s.

Observed timings

Observed lifecycle from one Slack reply:

Derived intervals:

Environment, sanitized:

• OpenClaw version: 2026.5.28
• Runtime shape: OpenClaw agent with Slack channel enabled and @openclaw/diagnostics-otel enabled
• OTel exporter: OTLP/HTTP to Tempo
• Model/provider span attributes present, including openclaw.provider, openclaw.model, openclaw.transport, and request byte count

Why this matters

The actual model call duration is mostly outside OpenClaw's control. The pre-call and post-call intervals are OpenClaw-owned and may contain actionable latency from session hydration, context assembly, prompt/input construction, request serialization, harness process readiness, adapter setup, or dispatch overhead.

The current span set shows that this overhead exists, but it does not break the pre-call path down enough to identify the owner.

Related observability issue: #88811 tracks correlation of Slack/channel message diagnostics into a single trace. This issue is about measuring and reducing OpenClaw-owned latency regardless of the final trace-correlation implementation.

Proposed work

Add focused diagnostics around the pre-model-call and post-model-call lifecycle so one message turn can be decomposed into actionable phases.

Potential spans or diagnostic events:

• inbound message dispatch
• duplicate detection / de-dupe
• session lookup or creation
• agent/session hydration
• context assembly
• prompt/input construction
• request serialization and byte-size calculation
• harness process acquisition, startup, or reuse
• provider adapter handoff immediately before openclaw.model.call
• response parsing
• reply formatting and channel delivery

Where possible, these should be groupable by a stable turn/message/session identifier, even before full trace parentage is fixed.

Success criteria

• One Slack/channel reply lifecycle can be decomposed into model-call time and OpenClaw-owned non-model time.
• The pre-call interval between openclaw.harness.run and openclaw.model.call is broken into actionable sub-intervals.
• Diagnostics include enough stable attributes to group related spans/events for one message turn.
• A benchmark or repeatable measurement report over several Slack/channel turns shows median and high-percentile timing for:
  • total message processing
  • pre-model-call overhead
  • model-call duration
  • post-model-call reply delivery overhead
• At least one identified OpenClaw-owned latency source has a concrete follow-up optimization path, or the measurements show the overhead is already near the expected floor.