Skip to main content

​
What is TTFS?

Time To Final Segment (TTFS) measures how long it takes from the moment a user stops speaking until the STT service delivers the final transcript. This latency directly affects how long your bot waits before it starts responding.
Every STT service has a different TTFS profile based on its architecture, model complexity, and infrastructure. Pipecat ships with measured P99 latency values for each supported service so that turn detection can account for this delay automatically. Measured values were benchmarked using the stt-benchmark tool.

​
Why TTFS matters

TTFS feeds directly into turn stop strategies, which decide when the user has finished speaking and the bot should respond.
  • Value too low: The turn stop strategy gives up waiting before the final transcript arrives. The bot responds based on incomplete text, or misses the user’s input entirely.
  • Value too high: The bot waits longer than necessary after the user stops speaking, creating awkward pauses in the conversation.
  • Value just right: The bot waits long enough for the transcript to arrive, then responds immediately.
Getting TTFS right is one of the most impactful tuning knobs for perceived conversation responsiveness.
TTFS is a configuration value the turn stop strategy uses, not a metric that is logged at runtime. To observe live latency in your running bot (time to first byte, user-to-bot latency), see the Metrics guide.

​
Default P99 latency values

Pipecat includes measured P99 TTFS values for every supported STT service. These are used automatically when you create a service — no configuration required. For the current P99 TTFS value for each service, see stt_latency.py. These values are refined and added to often, so the source file is the source of truth.
These built-in values were all measured with VADParams.stop_secs=0.2, the recommended default. If you change stop_secs, the built-in value no longer matches your setup and Pipecat logs a warning. Re-run the benchmark with your VAD settings and pass the measured value to your STT service constructor. See the Stop Strategies section for the full explanation of how this interacts with turn detection.
Local services (NVIDIA, Whisper) default to 1.0s since actual latency depends entirely on your hardware. Always measure and override for local deployments.
Turn-based STT services (for example CartesiaTurnsSTTService and DeepgramFluxSTTService) have no meaningful TTFS value. The server defines the turn boundary directly, so there is no separate “speech end to final transcript” interval to measure.

​
Measuring latency for your deployment

The default values are measured under standard conditions, but your actual latency depends on:
  • Network distance to the STT provider
  • Region where the service is hosted
  • Service configuration (model size, language, features enabled)
  • Audio quality and encoding settings
Use the stt-benchmark tool to measure TTFS for your specific setup. The tool sends standardized audio samples to your STT service and reports P50, P90, and P99 latency values. To run it, clone the repo and install with uv:
If you run your bot with a non-default VAD setting, match the benchmark to it with --vad-stop-secs so the measured value reflects your configuration:
See the stt-benchmark README for the full command reference.

​
Overriding the default value

Pass the ttfs_p99_latency parameter to any STT service constructor to override the built-in default:
This value is broadcast to the pipeline via an STTMetadataFrame at startup, so turn stop strategies automatically adjust their timing.
If you’re deploying to a specific region or using a self-hosted STT service, always measure and override the default TTFS value. Even small differences (e.g., 0.35s vs 0.55s) can noticeably affect conversation responsiveness.