busy-lunch-15701
03/06/2026, 9:26 AMtall-airline-16756
03/06/2026, 9:26 AMtall-airline-16756
03/06/2026, 9:26 AMEOUMetrics.timestamp represents. Good question.
• What it is: EOUMetrics.timestamp is the Unix timestamp for when an end-of-utterance (EOU) metrics event occurred.
• Format: It’s a floating-point value representing seconds since the Unix epoch (1970-01-01T000000Z).
• Why it’s useful: Use it to correlate the EOU event with other session logs or metrics (for example, to measure latency between speech end and system actions, or to align EOU events with other timeline events).
If you’d like, tell me:
• the format you prefer (milliseconds vs seconds), or
• an example payload you’re seeing — I can help interpret it or show how to convert it to an ISO timestamp.
For reference: STT Metrics | LiveKit Documentation: https://docs.livekit.io/recipes/metrics_stt
Sources: STT Metrics | LiveKit Documentationbusy-lunch-15701
03/06/2026, 9:26 AMtall-airline-16756
03/06/2026, 9:27 AMLLMMetrics.timestamp represents. Good question.
• What it is: LLMMetrics.timestamp is the Unix timestamp for when an LLM metrics event was recorded — specifically the moment the LLM finishes generating its response.
• Format: It’s expressed as seconds since the Unix epoch (a floating-point value). You can convert it to a human-readable datetime, for example in Python:
from datetime import datetime
datetime.fromtimestamp(metrics.timestamp).strftime('%Y-%m-%d %H:%M:%S')
• Why it’s useful: Use it to correlate LLM completion events with other session logs or metrics (latency measurement, ordering of events, or performance analysis across components).
If you want, tell me:
• whether you prefer the timestamp in milliseconds or an ISO string, and I can show conversion snippets; or
• share an example metric payload and I’ll help interpret it.
Reference: LLM Metrics | LiveKit Documentation: https://docs.livekit.io/recipes/metrics_llm
Sources: LLM Metrics | LiveKit Documentationbusy-lunch-15701
03/06/2026, 9:28 AMtall-airline-16756
03/06/2026, 9:28 AMLLMMetrics.timestamp marks the exact moment the LLM is done, and how certain that is. Short answer: yes — it represents the moment the LLM finished generating its response — but there are practical caveats to be aware of.
What LLMMetrics.timestamp means
• LLMMetrics.timestamp is the server timestamp recorded when the LLM metrics event was generated, specifically after the LLM completes its response generation.
• It is formatted as a Unix timestamp (seconds since epoch) and is intended to mark the completion time of the LLM response.
Certainty and practical considerations
• The timestamp indicates when the LLM finished on the server side (i.e., when the metrics were emitted). It is suitable for correlating events and measuring high-level latency (for example, response-generation time).
• Minor delays can exist between the actual internal completion moment and when the metric is recorded or logged (for example due to metric emission batching, logging latency, or network/processing overhead on the server). The timestamp still represents the server-side completion time, but it may not reflect nanosecond-accurate internal state transitions.
• If you need stricter guarantees about ordering or sub-millisecond precision, you should correlate this timestamp with other timestamps you control (for example, client-side send/receive times) and account for clock skew and measurement overhead.
If helpful, I can:
• Show code snippets to convert metrics.timestamp to ISO or milliseconds.
• Suggest how to correlate LLMMetrics.timestamp with client-side times to measure end-to-end latency.
Which would you prefer?busy-lunch-15701
03/06/2026, 9:29 AMtall-airline-16756
03/06/2026, 9:29 AMLLMMetrics.timestamp. Good question — you can calculate it if you have the right latency field.
• What to use: Subtract LLMMetrics.ttft (Time To First Token) from LLMMetrics.timestamp.
◦ Formula: LLM start time = LLMMetrics.timestamp - LLMMetrics.ttft
◦ Reason: LLMMetrics.timestamp marks when the first token (LLM output) was recorded; ttft is the elapsed time from request start to that first token.
• Notes and caveats:
◦ Both values are in seconds (floating point). Convert to milliseconds or ISO if you prefer.
◦ This gives the server-side start time as observed by metrics emission. Small delays (logging/metric emission or clock skew) may affect sub-millisecond accuracy.
◦ To measure true end-to-end latency, correlate this derived start time with client-side send timestamps and account for clock skew.
Would you like a short code snippet (Python or JavaScript) to compute and convert this into an ISO timestamp?
Sources: LLM Metrics | LiveKit Documentation | examples/voice_agents | livekit/livekit_composite | DeepWiki | How can I reduce latency in voice agents using STT, TTS and LLM? | LiveKit