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.