> ## Documentation Index
> Fetch the complete documentation index at: https://daily-main.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# STT Latency Tuning

> Measure and tune STT latency for better turn detection timing

## 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.

```
User stops → [TTFS latency] → Final transcript arrives → Bot starts
```

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](https://github.com/pipecat-ai/stt-benchmark) tool.

## Why TTFS matters

TTFS feeds directly into [turn stop strategies](/api-reference/server/utilities/turn-management/user-turn-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.

<Note>
  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](/pipecat/fundamentals/metrics).
</Note>

## 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`](https://github.com/pipecat-ai/pipecat/blob/main/src/pipecat/services/stt_latency.py). These values are refined and added to often, so the source file is the source of truth.

<Note>
  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](/api-reference/server/utilities/turn-management/user-turn-strategies)
  for the full explanation of how this interacts with turn detection.
</Note>

<Note>
  Local services (NVIDIA, Whisper) default to 1.0s since actual latency depends
  entirely on your hardware. Always measure and override for local deployments.
</Note>

<Note>
  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.
</Note>

## 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](https://github.com/pipecat-ai/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`](https://docs.astral.sh/uv/):

```bash theme={null}
git clone https://github.com/pipecat-ai/stt-benchmark
cd stt-benchmark
uv sync

# Add your provider API keys
cp env.example .env

# Download standardized audio samples
uv run stt-benchmark download --num-samples 100

# Run the benchmark for one or more services
uv run stt-benchmark run --services deepgram,openai

# View the P50/P90/P99 report
uv run stt-benchmark report --service deepgram
```

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:

```bash theme={null}
uv run stt-benchmark run --services deepgram --vad-stop-secs 0.3
```

See the [stt-benchmark README](https://github.com/pipecat-ai/stt-benchmark) 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:

```python theme={null}
from pipecat.services.deepgram.stt import DeepgramSTTService

# Use a measured value from your deployment
stt = DeepgramSTTService(
    api_key=os.getenv("DEEPGRAM_API_KEY"),
    ttfs_p99_latency=0.45,  # Override with your measured P99
)
```

This value is broadcast to the pipeline via an `STTMetadataFrame` at startup, so turn stop strategies automatically adjust their timing.

<Tip>
  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.
</Tip>