How to correlate per plugin metrics event with ChatMessage.metrics to calculate total latency

Agents
,
1

hi @LiveKit-Community @livekitteams
We are currently pulling end_of_turn_delay from Chat.metrics, but we still rely on the plugin-level metrics_collected events for TTFT and TTFB. Previously, we used the speech_id as a common key to map metrics (eou_delay, ttft and ttfb) for total latency calculations.
In the new migration, as ChatMessage.metrics (within conversation_item_added) does not include the speech_id,though it still exists in the LLMMetrics / TTSMetrics objects, how can we correlating these metrics to calculate total latency?

2

LLMMetric does still have speech_id. But if you just need to get the value for end to end latency it is now pre-calculated for you here in chat_context.

The session-level metrics_collected event is deprecated, and per-turn latency should now be read from ChatMessage.metrics in the conversation_item_added event. Per-plugin metrics_collected (LLM/STT/TTS) still emit detailed metrics such as TTFT/TTFB, but speech_id is no longer surfaced on ChatMessage.metrics for correlation. See Events and error handling and the linked per-turn latency section.

3

@Harshita_Sukumar_Patil, the MetricsReport TypedDict on ChatMessage.metrics already carries the per-plugin breakdown you’d otherwise correlate by speech_id. livekit/agents/…/llm/chat_context.py

So total latency calculation doesn’t require correlating the per-plugin metrics_collected events. e2e_latency is the pre-calculated end-to-end, and the component fields give you the same breakdown you previously assembled by joining on speech_id.

If you still want the per-plugin metrics_collected events for other reasons, speech_id is present on LLMMetrics, EOUMetrics, and TTSMetrics, but not on STTMetrics or RealtimeModelMetrics. livekit/agents/…/metrics/base.py. STT timing correlation via speech_id has never been possible; transcription_delay in MetricsReport is the STT contribution to per-turn latency.