Gemini 3.1 Flash TTS bills AUDIO tokens for minutes of digital silence

Gemini API
1

I’m seeing a reproducible billing/metering problem with gemini-3.1-flash-tts-preview while rendering a long-form audiobook.

The API is returning successful audio responses containing extremely long periods of silence, while usageMetadata counts the entire generated duration as AUDIO output tokens.

This is not a subjective audio-quality complaint. The defective output can be measured directly from the PCM samples.

Example failure

One request contained 2,989 characters of narration. A normal successful rendering of this passage is approximately 273 seconds.

The API returned HTTP 200 with a well-formed audio payload approximately 30 MB in size and 643 seconds long.

Analysis of the returned PCM:

  • 0–15s: speech
  • 15–75s: near-silence
  • 75–465s: every PCM sample is exactly zero
  • 465–495s: speech resumes
  • 495–643s: near-silence

Therefore, the response contained 390 consecutive seconds (6.5 minutes) of literal digital silence in the middle of the generated audio.

Measured speech ratio for the entire 643-second response was only 0.037.

The request nevertheless consumed AUDIO output tokens.

Billing impact

Across this audiobook render, approximately 2,000,000 AUDIO output tokens were recorded.

At the documented rate of 25 audio tokens per second, that represents approximately:

80,000 seconds / 22.2 hours of generated audio.

Only approximately:

7,753 seconds / 2.15 hours

of usable audio was ultimately retained.

In other words, approximately 90% of the metered output did not become usable narration, largely because defective generations had to be rejected and regenerated.

This appears consistent with other reports

I’ve found several reports involving the same model where:

  • audio is generated briefly and then becomes silent until the output limit while the silence continues consuming tokens;
  • near-silent audio is returned with finishReason: STOP;
  • HTTP 200 responses contain empty content while usageMetadata still reports AUDIO output tokens;
  • identical requests intermittently return empty/defective responses and then succeed when retried.

Question for the Gemini team

Is AUDIO token metering for extended digital silence an intended behavior of gemini-3.1-flash-tts-preview, or is this considered a model/metering defect?

Specifically, should a response containing hundreds of seconds in which every PCM sample is exactly zero continue accumulating billable AUDIO output tokens?

If this is a known issue, is there a recommended way for clients to identify the failure server-side before the silent output has already been generated and metered?

I can provide request metadata, additional measurements, and defective audio samples from future occurrences if useful for reproduction.

2

Update after additional testing (16 September):

I completed the remaining audiobook synthesis today using the same gemini-3.1-flash-tts-preview model and voice, with additional client-side validation and retry safeguards.

An important observation is that the defective generations appear to be probabilistic rather than input-dependent.

The same text can produce a defective response on one request and valid speech on a subsequent request without changing the input. In one test, identical content failed twice and then synthesized successfully on the next attempt. Other previously failing sections similarly succeeded when retried unchanged.

This suggests the failure is not necessarily caused by unsupported text or a deterministic prompt/input condition.

I have now added client-side safeguards that reject near-silent responses and cap retries/output length. With those safeguards, completing the remaining synthesis cost approximately $0.35.

These safeguards mitigate the financial impact, but they do not address the underlying issue: defective/silent AUDIO output has already been generated and metered before the client can inspect and reject it.

The question therefore remains whether AUDIO tokens corresponding to extended digital silence are intended to be billable output, particularly when an identical request can subsequently return normal speech.

3

Hello @Parth_Adhia ,

To help us debug this, could you share your Project ID, recent Request IDs or timestamps, and sample input text via direct message?

4

I’m signed in and ready to provide the Project ID, timestamps, and representative sample input privately, but I don’t see a direct-message option on the forum. Please let me know the secure channel you prefer.

5

Update — 30 September: I have now independently audited a second, separate Gemini 3.1 Flash TTS batch from 29–30 September. This is not the earlier 2-million-token batch, and the numbers should not be combined.

The new batch contains eight audio-bearing rejected WAVs and five later-superseded takes. A fresh PCM scan found seven long runs of exact-zero samples (about 29–79 seconds) across rejected/superseded outputs, plus a further 3.385-second exact-zero run. For example, English §15 returned 109.36 seconds of audio; only about 4.3 seconds was speech, and 78.628 seconds were consecutive exact-zero samples. A discarded Bengali §34 take had 48.253 seconds of exact zeros. Two responses returned no inline audio/PCM, yet their usageMetadata reported 2,119 and 3,839 AUDIO output tokens (finish reasons OTHER and SAFETY).

I sent the project ID, UTC timestamps, and a representative sample to Pooja in the existing private forum message. No request IDs were captured, so Google will need to match by timestamp. I have also replied to the related Cloud Billing case to request a separate billing review.

One metering clarification from the audit: Google’s Gemini 3.1 Flash TTS pricing page says audio tokens correspond to 25 tokens/second, while the separate audio-understanding documentation says 32/second; nonempty reject sidecars in this batch show about 32 candidates tokens/second. The repeated ~1.28 ratio against maxOutputTokens matches 32/25, so I am asking Google to explain the cap/metering units rather than asserting an over-cap charge. Billing reconciliation is still underway.

6

Update — Oct 2: The question I need answered is simple: why did Gemini 3.1 Flash TTS return long stretches of exact digital silence and, in two responses, no audio at all? Were those silent or empty outputs billed, and if so, why? My previous update documents the measurements.

I asked Cloud Billing Support to review the separate September 29–30 batch. Replies so far keep classifying an adjustment as a one-time courtesy because of an earlier, unrelated incident. They have not explained whether the new outputs were checked against billing records or whether charges for silent/empty output were correct. I am not asking for a blanket waiver or another goodwill gesture; I am asking for a product/billing review of the charges for unusable output and how they were calculated.

Could the Gemini TTS team confirm whether this behavior is expected and point to the right path for a billing-accuracy review? I have not included project/account identifiers or private payment details here.

7

Hello @Parth_Adhia ,

Thank you for sharing these details. Have you tried the same sections with gemini-3.8-flash-tts? If so, could you let us know whether you still see the long silent stretches or empty responses?