Enabling performance metrics
Setenable_metrics=True in PipelineParams when creating a worker:
Example config
Sample output
Limiting TTFB responses
If you only want the first TTFB measurement for each service, you can optionally passreport_only_initial_ttfb=True in PipelineParams:
Example config
Note: enable_metrics=True is required for this setting to have an
effect.
Disabling initial empty metrics
By default, Pipecat sends an initialMetricsFrame with zero values for all
services when the pipeline starts. To disable this behavior:
Example config
Enabling LLM/TTS Usage Metrics
Setenable_usage_metrics=True in PipelineParams when creating a worker:
Example config
Sample output
Note: Usage metrics are recorded per interaction and do not represent running totals.
Capturing Metrics Data
When metrics are enabled, Pipecat emits aMetricsFrame for each interaction. The MetricsFrame contains a list of metrics data objects, which can include:
TTFBMetricsData— Time To First ByteTTFAMetricsData— Time To First Audio (TTS)TTFATMetricsData— Time To First Answer Token (LLM)ProcessingMetricsData— Processing timeLLMUsageMetricsData— LLM token usageSTTUsageMetricsData— STT audio-seconds usageTTSUsageMetricsData— TTS character usageTextAggregationMetricsData— Sentence aggregation latency (TTS)TurnMetricsData— Turn completion predictions
MetricsFrames.
Example: Using MetricsLogObserver
The simplest way to log metrics is with the built-inMetricsLogObserver. Pass it as an observer when creating your PipelineWorker:
include_metrics:
Example: Using a Custom FrameProcessor
Create a custom FrameProcessor to handle metrics data. Here’s an example Metrics Processor that can be added to your pipeline after the TTS processor.Metrics Data Reference
All metrics data classes inherit fromMetricsData, which includes processor (the name of the processor that generated the metric) and an optional model field.
TTFBMetricsData
Time To First Byte — measures how long until the first byte of a response is received from a service.TTFAMetricsData
Time To First Audio — measures the time from a TTS request to the first audible audio sample. This includes the time to first byte plus any leading silence padding added by the service.TTFAMetricsData reports the latency breakdown directly, showing how much of the perceived latency is silence padding.
TTFATMetricsData
Time To First Answer Token — measures the time from an LLM request to the first token of the answer the caller sees. This is time-to-first-byte plus any reasoning the model streamed first.TTFATMetricsData reports the latency breakdown, showing how much of the perceived latency is the model thinking rather than responding.
A turn that answers with a tool call rather than text ends the measurement at the call. Answering from a tool result takes a second inference, so such a turn reports twice — once for the call, once for the answer built from its result.
Reported only by LLM services that answer in text. Speech-to-speech services answer in audio, which has no answer token to measure to.
ProcessingMetricsData
Measures the total time taken by a service to process a request.WebSocket-based TTS services (Cartesia, Deepgram, ElevenLabs WebSocket
variants) and
DeepgramSageMakerTTSService do not report processing metrics;
TTFB and TTFA capture the meaningful latency for these services. Streaming STT
services (subclasses of STTService) don’t report them either, because audio
arrives continuously and there is no discrete request whose duration a
processing window could measure; TTFB is the meaningful measurement there.
SegmentedSTTService subclasses do issue one request per utterance, so they
report both.TextAggregationMetricsData
Measures the time from the first LLM token to the first complete sentence, representing the latency cost of sentence aggregation in the TTS pipeline.LLMUsageMetricsData
Token usage for an LLM interaction. Thevalue field is an LLMTokenUsage object with:
STTUsageMetricsData
Audio usage for an STT interaction, measured client-side as the seconds of audio submitted to the service. Streaming services report incrementally, once per final transcript and again on stop or cancel; segmented services report once per transcribed segment.
Usage reaches RTVI clients as
stt_usage, is logged by MetricsLogObserver, and is attached to OpenTelemetry stt spans as metrics.audio_seconds.
TTSUsageMetricsData
Character usage for a TTS interaction.TurnMetricsData
Metrics from turn completion prediction, emitted by turn analyzers like Krisp Viva Turn and Smart Turn.Related Observers
In addition toMetricsLogObserver, Pipecat provides observers that track higher-level conversational metrics.