[bug] sustained sessions: agent_dispatch_ms spikes 3-5x after ~1hr (no recovery without /compact)

[RayKuo-Mantis]

Description

Bug: dispatch latency spike from ~30s to 2-5 min sustained

Symptoms

After ~1hr of normal operation, agent_dispatch_ms jumps 3-5x and stays elevated.
User-side perception: messages appear unanswered ("no response" feeling), reply
eventually arrives 2-5 min later.

Sample log data (2026-05-12 session)

Normal range (UTC 05:18 - 05:49):

06:18:51 agent_dispatch_ms=23052 (23s)
05:29:04 agent_dispatch_ms=56241 (56s)
05:35:52 agent_dispatch_ms=38295 (38s)
05:43:50 agent_dispatch_ms=25530 (26s)
05:49:23 agent_dispatch_ms=45365 (45s)
Spike begins UTC 06:33:

06:33:49 agent_dispatch_ms=74489 (74s)
06:41:09 agent_dispatch_ms=279310 (4.6 min) ⚠️
06:44:30 agent_dispatch_ms=183225 (3 min)
06:49:01 agent_dispatch_ms=124135 (2 min)
06:54:31 agent_dispatch_ms=202111 (3.4 min)
06:58:29 agent_dispatch_ms=167416 (2.8 min)
07:20:04 agent_dispatch_ms=226646 (3.8 min) ⚠️
07:23:31 agent_dispatch_ms=72705 (73s)
07:28:42 agent_dispatch_ms=59920 (60s)

Other metrics observed

• wait_ms: 281-692 ms throughout (queue wait healthy, dispatch itself slow)
• tokens_per_event: 5-99 (no obvious correlation to latency)
• packed_block_count: 2 (constant)
• events_per_dispatch: 1 (constant)

Possible root causes (untested)

1. Anthropic API end slowdown during the session
2. OpenAB internal queue bloat after sustained use
3. Context growth → Claude API slower per call
4. Session-level state accumulation in adapter

Environment

• OpenAB version: 0.8.3-beta.7-pr791 (local build with PR fix: reconnect Discord gateway on silent WS disconnect #791 reconnect fix)
• Adapter: discord
• Channel: thread under user channel
• Sustained session: ~3+ hours active conversation
• Manual /compact invoked once mid-session (recovered briefly per user obs)

Workaround

Manual /compact helps short-term per user observation 2026-05-11 14:54 UTC.
Recovery not durable — latency creeps back within ~1hr.

Ask

• Is agent_dispatch_ms measuring inclusive of Anthropic API call duration?
  If yes, may be upstream issue. If exclusive, OpenAB internal latency to
  investigate.
• Auto-compact (which user notes is missing per separate report) would
  likely help here too.

Repro

1. Start OpenAB Discord session
2. Sustain conversation for 3+ hours active
3. Observe agent_dispatch_ms creep 30s → 2-5 min
4. /compact resets briefly then climbs again

Logs available on request.

Steps to Reproduce

discord (no response)

Expected Behavior

discord responses.

Environment

No response

Screenshots / Logs

No response

[CHC-Agent]

Issue at a Glance

User msg → OpenAB dispatch → Claude CLI (ACP) → Anthropic API → stream back
           ├─ wait_ms ─┤     ├──────── agent_dispatch_ms (single number) ────────┤
           (healthy)          (no sub-breakdown available)

Hi @RayKuo-Mantis,

Confirmed from source (src/dispatch.rs:681, src/adapter.rs:532): agent_dispatch_ms is a single end-to-end measurement covering the entire stream_prompt_blocks() call — inclusive of ACP session communication, Claude CLI processing, Anthropic API latency, and Discord streaming. There is currently no sub-metric breakdown within this span.

This means the current instrumentation cannot pinpoint whether the latency growth is caused by Anthropic API slowdown (larger context → slower response), Claude CLI internal overhead, or another factor. The /compact recovery pattern strongly suggests context size is the dominant factor, but without finer-grained timing we cannot confirm.

Suggested next step: add sub-metrics to the dispatch path, e.g.:

• ttft_ms — time from prompt sent to first ACP event received (isolates API/thinking latency)
• tool_ms — cumulative time spent in tool calls
• stream_ms — total streaming duration

With these in place, a reproduction of the spike would immediately reveal which segment is growing.

Related:

• Discord adapter: latency UX improvements (perception + proactive context management) #795 by @RayKuo-Mantis — OPEN (proposes auto-compact and latency UX improvements as structural fix)

Next step: add observability instrumentation to narrow down the root cause. A PR adding sub-metrics to the dispatch loop is welcome.

[github-actions]

⚠️ This issue is missing the following required information and will not be processed until completed:

• Description

Please edit this issue to fill in the missing fields. Thank you!

Tip: Use headings like ## Description or ### Description — common synonyms (e.g. ## Problem, ## Reproduction, ## Motivation) are also accepted.