Built a small open-source latency waterfall for voice agents — it records user-stop → STT final → LLM first token → TTS first byte → playback (plus each tool/function call as its own timeline segment) and renders a per-turn waterfall + p50/p95 across runs, so you can see which stage is eating your turn budget.
Has a Pipecat observer today; LiveKit Agents support is next on my list — curious what folks here use to chase per-turn latency right now?
Built a custom solution for it, let me know when you are done building it out for livekit!
Why not just use the one built into LiveKit?
Also have a look at this:
Also, if you are latency conscious you may want to try:
Latency Optimized Inference: Gemma 4 on LiveKit
Fair question! LiveKit’s per-turn metrics are great — honestly that’s what I’d build on top of, not replace. The gap I keep hitting (I’m not alone — e.g. agents#3824): the component numbers don’t always reconcile with the actual observed silence, and tool-call time isn’t attributed. voxprofile plots the observed per-turn waterfall on a single clock (matches reality, not a formula), shows each tool call as its own segment, and tracks p50/p95 across runs — and it’s framework-agnostic + local, so teams on both Pipecat and LiveKit get one view without the Cloud observability spend. A LiveKit metrics adapter is next on my list — would love your feedback on the mapping when I get there 
Will definitely ping you when the LiveKit adapter lands Since you built your own — what does yours capture that you’d want to keep (per-turn waterfall? tool-call time? cross-run tracking?), and what was the annoying part? Trying to make the LiveKit version genuinely useful. Happy to hand you an early build to try.
Ours is pretty simple, custom latency tracking per turn: TTFT, LLM latency, TTS first byte, TTS latency, and total turn latency. Our whole use case is keeping turns sub-700ms, so that’s what we optimize around.
We wanted to use LiveKit’s built-in tracking but it was missing a lot for realtime models, that was the annoying part. Tool-call time isn’t a KPI for us.
Would definitely try an early build, espically since new models are coming, super excited about gpt-live-1 
This is super helpful, thanks Sub-700ms as the north star makes total sense — voxprofile already does pass/fail against a turn budget like that.
The realtime-model gap is the part I want to dig into: what specifically was LiveKit’s built-in missing for realtime models — is it that the STT→LLM→TTS breakdown doesn’t map when it’s one speech-to-speech model, missing sub-events, or something else? That’s exactly what I want the LiveKit adapter to nail.
I’ll ping you with an early build — best way to reach you, DM here or GitHub?