Adnan Ali

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.

Thank you Mateo, I am glad it resonated!