Research-backed calculator guide

Barge-In Cost in Voice Agents: Price Cancelled TTS, Extra Turns and Wasted Audio

Learn how to price voice-agent interruptions by separating generated, played, cancelled, and follow-up audio instead of treating every barge-in as one flat cost.

● First-party sources checked▧ Original calculation examples◌ Estimate, not a vendor quote

Quick answer

Barge-in does not have one universal price. The cost of an interruption depends on what your stack has already generated, what the caller actually heard, what audio remains buffered, and whether the interruption creates another speech-recognition or language-model turn. A useful estimate is:

interruption cost = billable TTS already submitted + extra STT audio + extra LLM turn + incremental platform or telephony time − costs that your provider does not charge or that your design avoids.

The key distinction is between wasted audio and unbilled audio. If a provider bills submitted characters, cancelling playback after 300 ms may not refund characters already sent for a 3-second sentence. If a provider meters generated audio duration, the cancelled tail may be cheaper than a fully rendered turn. If the system streamed only a small next chunk, the ungenerated tail is not waste at all. You must map the interruption event to the provider’s actual meter rather than multiply “interruptions” by a guessed flat fee.

For accounting, log at least these fields per assistant turn: text characters or output tokens submitted, audio generated, audio played, audio discarded, interruption timestamp, input audio seconds, follow-up input/output tokens, provider model, and billable unit. Deepgram’s official Flux TTS interruption flow is a useful example: stop local playback immediately, send the playback offset, discard in-flight frames, and reconcile text_spoken with text_remaining.[1] OpenAI’s Realtime guide describes the same accounting principle through response cancellation and truncation of unplayed audio.[2]

What creates cost when a caller interrupts?

A barge-in is an interaction event, not automatically a new invoice line. The caller begins speaking while the agent is speaking. Your controller then decides whether that speech is a genuine interruption or background noise, stops playback, cancels work, and starts the next turn. Each decision can touch a different meter.

Text generation. The language model may have already produced the whole response before the caller interrupts. If the response was generated in one request, cancelling playback does not necessarily undo input or output tokens. If generation is still streaming, cancellation may prevent future tokens, but only your usage event can confirm what was consumed.

Text-to-speech. TTS may be priced by characters submitted, characters synthesized, audio seconds, request count, or a bundled voice-agent unit. “Cancelled TTS” therefore means different things across providers. Store both the text sent to TTS and the portion that was rendered or played. Do not label every unplayed character as a refund or every discarded frame as a billable charge.

Speech-to-text. The caller’s interruption itself is input audio. A short correction adds seconds to streaming STT, although the session may already be open and priced by connection time or minimum increments. Deepgram’s metrics documentation illustrates why unit names matter: its example billing metrics distinguish consumed units, processed audio seconds, and synthesized character count.[3]

The follow-up turn. A genuine interruption normally causes another transcript, model request, and TTS response. That next turn is often the largest incremental cost when the original TTS was short but the correction triggers a tool call or a long answer. Track it as a child turn linked to the interrupted parent, not as an untraceable “barge-in fee.”

Telephony and platform time. If the call remains connected, an interruption can extend the call or simply replace speech that would have happened anyway. Charge incremental seconds only when the call or platform meter actually increases. Otherwise, adding a full per-minute fee to every interruption double-counts the call’s base duration.

A cost-event ledger for interrupted speech

Use a ledger with one row for each attempted assistant utterance. The following sequence is practical for either a hosted voice agent or a custom streaming pipeline:

  1. Record the assistant text submitted to the model-to-speech layer and the selected billing unit.
  2. Record TTS-generated duration or characters returned before cancellation.
  3. Record the local playback position at the interruption. This is the closest operational measure of what the caller heard.
  4. Stop local playback and flush queued audio. OpenAI explicitly instructs WebSocket clients to stop playback, discard queued audio, and send the played duration for truncation.[2]
  5. Record the discarded tail separately from the generated prefix. Deepgram’s text_spoken and text_remaining fields provide a concrete pattern for this reconciliation.[1]
  6. Link the caller’s STT event and the follow-up LLM/TTS turn to the interrupted turn ID.
  7. Join the event row to the provider usage export or invoice. Provider documentation, not an assumed rate, decides whether each field is billable.

This design also protects conversation quality. If the model sees the full sentence even though the caller heard only its first clause, it may refer to information that was never delivered. Truncating unplayed output keeps the conversation state aligned with the audio experience.[2]

Worked cost example

Consider a small production workload. These rates are illustrative estimates for arithmetic, not vendor quotes, and are intentionally easy to replace with the rates and units in your contract.

StepAssumption or inputCalculationOutput
Calls per month1,000 calls; 3 assistant turns per call1,000 × 33,000 attempted turns
TTS text650 characters per attempted turn3,000 × 6501,950,000 submitted characters
Interruption volume18% of assistant turns are interrupted3,000 × 0.18540 interruption events
Playback pointInterrupted turns reach 45% of their planned playback650 × 0.55 × 540193,050 unplayed characters, if the full text was submitted
TTS estimate$16 per 1,000,000 submitted characters1,950,000 × $16 / 1,000,000$31.20 total TTS estimate
Avoidable TTS scenarioTail is not submitted when streaming in small chunks193,050 × $16 / 1,000,000$3.09 potentially avoidable TTS spend
Follow-up LLM turn240 input tokens at $0.50/M and 90 output tokens at $1.50/M540 × [(240 × .50 + 90 × 1.50) / 1,000,000]$0.14 estimate
Interruption STT1.4 additional seconds at $0.010/minute540 × (1.4 / 60) × $0.010$0.13 estimate
Incremental example totalAvoidable TTS plus follow-up LLM and STT only$3.09 + $0.14 + $0.13$3.36/month

The table shows two different totals on purpose. The $31.20 is the hypothetical monthly TTS charge if all 1,950,000 characters are submitted and priced at that assumed character rate. The $3.09 is not an automatic refund. It is the amount that could be avoided if the application’s streaming policy prevents the unplayed tail from ever being submitted and the provider bills only submitted characters. If your provider accepts a complete request at once, cancellation may leave the $31.20 unchanged.

The $0.14 follow-up model cost assumes every interruption creates exactly one small follow-up request. Tool calls, retries, longer context, or a larger response would increase it. The $0.13 STT amount assumes the session is priced by incremental audio minutes. A provider that bills a minimum session, connection duration, or bundled voice-agent unit may show no separate $0.13 line. This is why invoice reconciliation should use event-level dimensions instead of a generic “interruption rate.”

How to estimate your own barge-in pricing

Start with a 24-hour or seven-day sample, not an average copied from another deployment. For each assistant turn, calculate:

played ratio = audio played milliseconds ÷ audio generated milliseconds

discard ratio = max(audio generated − audio played, 0) ÷ audio generated

Then segment the result by provider, model, transport, and interruption reason. A false VAD trigger has a different cost profile from a useful correction. A false trigger may create a replacement response that nobody needed, while a genuine correction may prevent the agent from finishing a long explanation and reduce total call time.

Next, classify your TTS billing basis:

  • Submitted-character meter: cancelled text already sent can remain billable. Chunking and delayed synthesis can reduce the tail, but may add requests or latency.
  • Generated-audio meter: compare the provider’s generated duration with local playback. A network buffer can make “generated” exceed “heard.”
  • Connection or bundled meter: interruptions may change quality and latency without creating a separable TTS charge. Attribute the event for unit economics, but do not invent a new invoice line.
  • Hybrid meter: some providers combine model tokens, audio seconds, and session time. Keep each meter in its native unit before converting to dollars.

Deepgram’s documented metrics pattern is a useful reconciliation model because it distinguishes consumed units from audio duration and character counts, with sums over a period representing billed volume for its SageMaker integration.[3] Your provider may use different names, so copy the exact usage field and unit into the ledger.

Ways to reduce wasted audio without making turn-taking worse

Generate closer to the playback frontier. Streaming a long paragraph into TTS before the caller has finished listening creates a larger cancellation tail. Smaller semantic chunks reduce unplayed work, but too many small requests can increase request overhead and make prosody less natural. Test chunk size against p95 response latency and TTS request cost.

Separate stop latency from context reconciliation. Playback should stop locally as soon as a real interruption is detected. Do not wait for a server acknowledgement before muting queued audio. The server event can then tell your ledger what was spoken and what remained. This is the sequence documented for Deepgram Flux TTS.[1]

Flush every downstream buffer. Stopping the synthesizer while RTP, WebSocket, browser, or SIP buffers still contain audio does not stop the caller from hearing it. Count queued audio as discarded and investigate why it remained in flight. A state-machine or trace view should show cancellation of the model, TTS, and playback queue as related events.

Avoid treating every VAD event as a paid turn. Use a minimum speech duration or semantic gate for likely backchannels, but measure missed interruptions as well as false stops. A stricter gate may lower replacement-turn spend while increasing caller repetition and call duration. The cheapest audio is not useful if it creates another failed attempt.

Reconcile to the invoice. Join your ledger to usage exports weekly. The AI API invoice reconciliation calculator can help compare estimated units with actual invoice rows, while the AI token cost calculator is useful for the model-token portion of each replacement turn. For mixed providers, use the model pricing comparison to normalize units before comparing effective costs.

Run your scenario

Turn this framework into an editable estimate.

Use dated, source-linked assumptions and see cost per request, successful task and month.

Mistral and Groq API cost calculator

Open the Mistral and Groq API cost calculator when you want to extend the same unit-by-unit method to a broader model workload.

What not to include in a barge-in cost estimate

Do not claim that an interrupted turn costs zero because the caller heard only half of it. Do not claim that it costs the full response unless your usage record shows that the full response was metered. Do not apply a telephony per-minute rate to every interruption when the call would have lasted the same amount of time. Do not add a platform fee because a cancellation event exists if the platform’s contract bills only connection time or bundled sessions.

Also keep quality economics separate from API spend. False stops can lower containment, cause transfers, or require a human to repeat a workflow. Those outcomes can matter financially, but they need their own measured value assumptions. If you model them, label the result as a business-impact estimate rather than provider cost.

Frequently asked questions

Does barge-in always create an extra TTS charge?

No. It creates an interruption event, but the charge depends on the meter. A provider might bill text submitted before cancellation, generated audio duration, request count, session time, or a bundle. Log submitted text and generated audio, then compare both with the provider’s usage record. A cancelled tail is potentially avoidable only when it was not submitted or generated under the applicable meter.

How do I calculate the cost of interrupted TTS?

Measure the interrupted turn’s billing unit before cancellation, the playback position, and the remaining text or audio. Multiply only the billable quantity by the verified unit rate. For example, if 650 characters were submitted and the provider bills submitted characters, the whole 650-character request may be charged even when only 45% played. If text was chunked and the final 55% was never submitted, that tail can be excluded from the estimate.

Should the replacement LLM turn be counted as a barge-in cost?

Yes, when it is caused by the interruption, but keep it as a separate child event. Count its input tokens, output tokens, cached context, tool calls, retries, and its own TTS. This makes it possible to tell whether the main expense is discarded speech or the longer workflow that follows the caller’s correction.

Does stopping playback remove unplayed audio from conversation history?

Not automatically in every architecture. OpenAI’s Realtime documentation says the client or server must truncate unplayed output so the conversation reflects what the user actually heard.[2] Deepgram’s Flux TTS flow similarly returns spoken and remaining text for context reconciliation.[1] Your ledger should store the playback offset and whether truncation succeeded; otherwise later responses may repeat or rely on unseen text.

How should I price a false interruption?

Price it as a counterfactual replacement event. Record the unnecessary cancelled TTS, any follow-up STT and LLM work, extra playback, and any measured call-time or transfer effect. Compare that with the cost of a missed interruption, which may be a repeated caller utterance or abandonment. There is no universal “correct” false-interruption price because the outcome depends on the workflow and the provider meters.

Primary sources checked

Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.

  1. Deepgram Flux TTS interruption handling
  2. OpenAI Realtime conversations: interruption and truncation
  3. Deepgram enhanced metrics and billing units

About the Author

Zunair Ali Syed is a doctoral researcher in Management Sciences at Minhaj University Lahore and a research consultant with experience in academic research and editing since 2011. He runs QuickEduHelp, with professional interests in digital learning, research methods, and evidence-based academic support.