Good catch - not captured as its own metric today. Here's what I found checking it, rather than assuming:
The two traces (same session, keyed on threadId):
trace 9dbc5698… (awaiting_approval)
start: 08:43:52.010
latency: 2.63s
→ ends (card appears): ~08:43:54.64
trace c7b8378c… (resume)
start: 08:44:10.000
First pass: diff the two trace timestamps directly → 17.99s ≈ 18s. That's what I almost replied with.
Problem: that folds in the 2.63s of model latency from the awaiting_approval trace itself - the exact thing your question is getting at.
Corrected: using the trace's end (start + latency) instead of its start:
08:44:10.000 − 08:43:54.64 ≈ 15.4s — that's the actual human decision time.
Not wired up as a derived metric yet, but fully recoverable from data Langfuse already has - threadId gets you the session, start+latency on each trace gets you the boundary. Computing this automatically per session and attaching it as a score would be the natural next step, same pattern as the finish_reason metadata.
I hope this checks out.
Kartik N V J K
Keeping instrumentation one level below the AG-UI event stream, so a third transport inherits tracing for free, is a clean call. I have hit the same approval-boundary issue where a pause and its resume split into two disconnected traces, and stable session keying is the only thing that makes latency there measurable. Are you capturing human wait time separately from model latency in that session?