Piper TTS on 271 phone calls: what one deployment measured

Piper TTS results at a glance

Every figure in this table comes from phone calls carried by Telnyx between 25 August and 24 September 2026, and each row names its own sample. Times are when APIFleet's server observed an event, not when the caller heard it, and p75 and p90 are the values that 75% and 90% of replies or calls stayed under.

Where these numbers come from

APIFleet records a timestamped trace event at each step of a call, and this page uses a de-identified extract of those traces. It keeps the 271 phone calls whose assistant spoke through Piper, all of them inbound over Telnyx, from 25 August to 24 September 2026, with calls on each of those 31 days.

One booking assistant on APIFleet made 263 of the 271 calls (97%), and a second assistant in the same account made the rest. This is one deployment, so every number here also reflects its prompt, its tools and its callers.

The calls were short: the median lasted 12.4 seconds, and 118 of the 271 (44%) lasted less than 10 seconds. The phone traffic may include developer test calls, and the 2 browser test calls with Piper were too few to report, so every figure on this page is from the phone channel.

Times are server observation times, taken when APIFleet's server recorded each step. Phone audio then leaves in 20-millisecond frames through the carrier's own buffering, so a caller hears each moment somewhat later than measured here.

APIFleet publishes this page and hosts the Piper service it measures. The numbers are reported as recorded, and their limits have a section of their own below.

Response latency after the caller's turn

On Piper phone calls from 25 August to 24 September 2026, the median reply reached first audio 1,080 ms after the caller's turn was finalized (614 replies on 121 calls; p75 1,373 ms, p90 1,906 ms). Resampling calls gives a 95% interval of 1,042 to 1,120 ms for that median, and that interval describes uncertainty for these calls only.

The clock starts when Deepgram Nova-3 finalizes the caller's turn, which happens only after the silence set by Deepgram's endpointing parameter or after a backstop timer on lines that never fall quiet (APIFleet's server defaults are 200 ms and 1,000 ms). It stops when the first reply audio reaches APIFleet's server, so the gap a caller experiences also includes that silence, the carrier's buffering and the network.

Replies where a tool call finished before the first audio are excluded and reported separately: 52 such replies on 37 calls had a median of 2,967 ms. That group also holds goodbyes before an instant end_call and replies already queued when a tool finished; only 19 of the 52 waited on a tool started in that turn (see the tool-call latency answer). Included are the 103 replies (17% of 614) that opened with the short progress phrase the runtime speaks while a tool runs; without them, the median was 1,042 ms (511 replies on 111 calls).

Removing the busiest day, 30 August, which held 30 of the 271 calls (11%), leaves the median at 1,081 ms (555 replies on 108 of the 241 remaining calls). The busiest day does not drive the result.

Where the time went: model, chunking and Piper

For the 511 replies that began with model text (111 calls), the trace splits the wait into four stages that add up exactly, reply by reply, to a median total of 1,042 ms. The language model's wait for its first token was the largest stage at a median 814 ms, while Piper's step took a median 133 ms.

Medians of stages do not add up to the median of the total, which is why 814, 54 and 133 ms sum to 1,001 ms rather than 1,042 ms. The speech-to-text row is only a rough proxy, from the last interim transcript to the final one, and it is not part of the total.

These calls also sent the model a lot of prompt text: a median of 114,840 text input tokens per connected minute (120 calls of 10 seconds or more with recorded tokens), a billing count that is only a rough proxy for prompt size. It counts the prompt and history re-sent with every model request, not audio, and prompts differ between deployments, so compare the model stage across them with care.

Why Piper's first audio waits for a whole chunk

Piper's development has moved to the OHF-Voice piper1-gpl project, and the original rhasspy/piper repository was archived in October 2025. The piper1-gpl HTTP server returns one complete WAV file for each POST to its /synthesize endpoint, while the documented ways to stream audio are the Python API, which yields audio in chunks, and the command-line tool's raw output.

APIFleet runs that stock HTTP server, from piper-tts 1.7.0, in its own container on the same private network as its voice server, and the server keeps the voice model loaded between calls. Piper's documentation recommends the web server for repeated use because the command-line tool loads the model on every run.

APIFleet sends one request per text chunk, waits for the complete WAV, converts Piper's 22,050 Hz audio to 8 kHz μ-law for the phone line, and hands the whole chunk to the call at once. The first audio of a reply therefore cannot arrive until Piper has synthesized every word of the first chunk, and each later chunk is requested only after the one before it has returned. The measured Piper stage covers that whole step: the HTTP round trip to the Piper container, synthesis of the full chunk and the audio conversion.

To keep that first wait short, APIFleet's chunker releases a reply's first chunk at the first sentence end at or after 12 characters, at a clause or word break once 70 characters are buffered, or when the reply ends; both limits are platform defaults. In this deployment the median first chunk was 25 characters (p90 57) across 511 replies on 111 calls, and only 1 of them reached 70 characters.

Longer first chunks took longer to come back, consistent with whole-chunk synthesis: a median 107 ms under 30 characters (289 replies on 84 calls), 155 ms at 30 to 49 (144 replies on 75 calls) and 206 ms at 50 or more (78 replies on 43 calls). The band edges were set from sample counts alone, so that every band holds at least 20 calls, and the bands also differ in what the model was saying. Read them as a size guide for this deployment, not as a speed constant for Piper.

Whole-chunk buffering also changes the order of trace events. The runtime records its inferred hang-up as soon as a farewell's text exists, which with Piper comes before the farewell's audio, and an earlier pass of this analysis misfiled 46 farewell replies as tool waits for that reason before it was corrected.

Greeting time: the opening line in one request

The opening line's audio reached the server a median 549 ms after the session started (269 phone calls from 25 August to 24 September 2026; p75 726 ms, p90 1,962 ms; call-level 95% interval 535 to 564 ms). The clock starts when APIFleet's session starts, after the carrier has answered and the media connection is open, so those steps are not included.

The greeting is where whole-chunk synthesis is easiest to see, because APIFleet sends the entire opening message to Piper as one request. Across the same 269 calls, that request started a median 2 ms after the session did and its audio came back a median 543 ms after the request started, so nearly all of the greeting time is the Piper request for the whole line.

Two of the 271 calls ended before any assistant audio reached the server, both in under 10 seconds. Removing the busiest day leaves the greeting median at 551 ms (239 calls).

Errors, dropped connections and silent calls

None of the 271 Piper phone calls from 25 August to 24 September 2026 ended with a pipeline error, that is a TTS, speech-to-text, language-model, assistant or setup failure; with zero in 271, the rule of three puts the 95% upper bound at about 1.1%. One call (0.4%) ended because the carrier connection was lost, and none of the 153 calls that lasted 10 seconds or more went without assistant audio.

In this pipeline, a Piper request that fails or passes its timeout (10 seconds by default) is reported as a fatal TTS error that ends the call with a tts_error reason, so a Piper failure during a call would normally appear in that count; the traces of these 271 calls hold no pipeline-error event of any kind. The count cannot catch audio that played but sounded wrong.

The caller's side ended 201 of the 271 calls, the assistant ended 68 itself, one was transferred and one lost its connection.

Two VCTK voices with 20 or more calls

Both voices are speakers in Piper's multi-speaker en_GB-vctk-medium model, which its model card describes as a medium-quality, 22,050 Hz voice with 109 speakers, trained on the VCTK corpus and fine-tuned from a US English voice. APIFleet's voice catalogue labels speakers p288 and p340 as Irish female voices.

The rows below are not a voice comparison. Both voices were used mainly by the same assistant but never on the same day: speaker p288's 200 calls ran from 25 August to 24 September, while p340's 60 calls fell on five days from 26 to 30 August, and 6 of p340's calls used a different language model.

A third speaker carried the other 11 calls, under the 20-call floor, so it has no row. Nothing in this data rates voice quality or caller preference.

Cost per connected minute when TTS is $0

Across the 271 phone calls and 185.55 connected minutes from 25 August to 24 September 2026, the estimated cost was $0.0307 per connected minute: $0.0176 for the language model, $0.0076 for Deepgram speech-to-text, $0.0055 for the carrier and $0 for Piper. For calls of 10 seconds or more, the per-call median was $0.0324 per minute (153 calls; p90 $0.0441).

These are estimates from APIFleet's configured rate cards, not invoices, and the carrier line is a flat configured Telnyx rate. Piper is priced at $0 because the platform hosts the Piper service and APIFleet's rate card charges nothing per Piper character, so the CPU, memory and operations behind it are not in any figure here.

The estimates also leave out APIFleet's platform fee of $0.03 per connected AI minute, billed per second, with AI providers and the carrier billed on top. For comparison, Vapi's pricing page, checked on 29 October 2026, lists $0.05 per minute for Vapi hosting on its pre-paid, usage-based option.

Confounders and limits of this data

This is observational production data, not a controlled benchmark: nothing was randomised, and no other TTS spoke on the same calls. One assistant made 97% of the calls, and with only two assistants the intervals here describe these calls, not other Piper deployments.

The language-model stage took most of the measured time and depends on the model and prompt, and the endpointing silence sits before the clock starts; all of these would differ in another deployment. The extract does not record this assistant's speech-to-text timing or Piper speaking-rate settings, which APIFleet lets each assistant override.

Traffic was light, 271 calls over 31 days with the busiest day holding 30 of them (11%), so these numbers do not show how Piper behaves when many calls share one CPU, and a Piper server on a different network would add travel time to every request. Many calls were very short, some may be developer tests, the platform's code has changed since September, and none of these figures measures voice quality or caller satisfaction.

How to run Piper TTS on phone calls

These practices follow from the code path and the Piper documentation described above. They are recommendations, not results measured in this data.

1. Run Piper's HTTP server as a long-lived service with the voice already loaded, not the command-line tool, which loads the model on every run.
2. Keep that server on a private network; its documented HTTP API describes no authentication.
3. Split replies into sentence-sized chunks and keep the first one short, because each chunk's audio arrives only once the whole chunk is synthesized.
4. Send a long opening line as sentences, or render a fixed greeting once and replay it, if the first second of the call matters to you.
5. Convert the 22,050 Hz output with a filtering resampler, because a phone leg carried as 8 kHz μ-law cannot take Piper's audio as it is.
6. Give every request a timeout and treat a failure as a call-level error, so a stalled synthesis is visible rather than silent.
7. Load-test simultaneous calls on the CPU you will use, and measure first audio per chunk under that load.
8. Budget for the server, and check the licences: the piper1-gpl runtime is GPL-3.0 and the VCTK voice's training data is licensed CC BY 4.0.

Continue with a practical next step

• Piper integration: setup, testing and cost boundary
• Deepgram transcription settings for cascading assistants
• APIFleet platform fee and billing
• Estimate platform, provider and carrier costs per minute
• What a voice agent actually costs per minute
• TTS models compared on real phone calls
• Which TTS reached first audio fastest on phone calls
• How long tool calls kept callers waiting
• Speech-to-speech models measured on the same platform
• Why small voice comparisons need an A/A noise floor

Frequently asked questions

Is Piper TTS fast enough for phone calls?

In this one deployment it was a small part of the wait: Piper's audio came back a median 133 ms after APIFleet handed it a reply's first text chunk (511 replies on 111 phone calls, 25 August to 24 September 2026), while the language model's first token took a median 814 ms. Traffic was light, so measure first audio on your own CPU and call volume before relying on it.

Does Piper stream audio over HTTP?

Not in the stock HTTP server, which returns a complete WAV file for each request; Piper documents streaming through its Python API and the command-line tool's raw output instead. APIFleet sends one HTTP request per sentence-sized chunk, so each chunk's audio arrives only when that chunk is fully synthesized.

Is Piper TTS free?

It has no per-character fee, and APIFleet's call logs price it at $0, but the server that runs it costs money and is not in that $0. On APIFleet the platform fee of $0.03 per connected AI minute, billed per second, still applies, with AI providers and the carrier billed on top.

Which Piper voices did these calls use?

Speakers p288 (200 phone calls) and p340 (60 phone calls) from the multi-speaker en_GB-vctk-medium model, between 25 August and 24 September 2026, with a third speaker on the other 11 calls. APIFleet's catalogue labels p288 and p340 as Irish female voices; this data does not measure voice quality.

Why did the greeting take longer than a reply's first audio?

APIFleet's code sends the whole opening message to Piper in one request, so nothing plays until all of it is synthesized; that request took a median 543 ms (269 phone calls, 25 August to 24 September 2026). A reply's first audio waits only for its first chunk, a median 25 characters that came back in a median 133 ms (511 replies on 111 calls), but the extract does not record greeting length, so this explains the gap from the code rather than measuring it.

Sources and evidence

• Piper (OHF-Voice/piper1-gpl): project README and licence · observed 2026-10-29
• Piper documentation: HTTP web server API · observed 2026-10-29
• Piper documentation: Python API and streaming · observed 2026-10-29
• Piper documentation: command-line interface · observed 2026-10-29
• rhasspy/piper: archived repository and move notice · observed 2026-10-29
• Piper 1.7.0 source: HTTP server (http_server.py) · observed 2026-10-29
• Piper voices: en_GB vctk medium model card (revision APIFleet pins) · observed 2026-10-29
• Deepgram documentation: Endpointing · observed 2026-10-29
• Vapi pricing: pre-paid hosting fee per minute · observed 2026-10-29