False-positive PROHIBITED_CONTENT on non-explicit text — gemini-2.5-flash-tts

Gemini API
1

I’m using gemini-2.5-flash-tts (paid tier, generateContent API) to generate read-aloud audio for a published romance novel I own. Twenty chapters generated without issues.

One 751-character section failed 4 times in a row with identical results: HTTP 200, no audio part, candidate.finishReason: UNKNOWN, promptFeedback.blockReason: PROHIBITED_CONTENT. Deterministic, not transient.

Here’s the full blocked passage:

She looks at me expectantly; I remember it vividly. If I wasn’t doing triple salchows, I was shooting a puck. I was always exhausted, and it sucked. I had no life.

I continue to glare.

Uncomfortable, my mother looks away. “Anyway, I thought I would share it with you and Violet. I suppose I should’ve knocked.”

“Damn right you should have!”

She tosses the dishtowel on the counter. “Don’t you take that tone with me! I didn’t expect your little girlfriend to be parading around half-naked!”

Her implication is clear: she believes Violet is trying to take advantage of me. I don’t get it. My mother has always had her head so far up her ass when it comes to me. It’s as if I’m still a teenager, not a grown man who can make his own damn decisions.

There is no sexual content in this text. It’s a character arguing with his mother.

Why this is a false positive rather than a policy disagreement:

• The three sections immediately before this one — which contain explicit sexual language — generated successfully.

• Five other chapters in the same book, each with a higher density of explicit terms than this chapter, generated successfully.

• The most explicit passage in this very chapter was never even reached; generation stopped at this section.

The filter blocked a non-explicit family argument while passing actually-explicit content in the same book. That points to a classifier misfire, not the policy working as intended. Could someone on the team review this?

2

Hi @Julie_David,

The configurable safetySettings thresholds only apply to the four adjustable categories covered in our Safety filters documentation, whereas PROHIBITED_CONTENT is returned by built-in core harm protections that remain active regardless of safetySettings.

Could you please test whether you still encounter this issue using gemini-3.8-flash-tts?

3

Thanks for the clarification!

I’ve since migrated my TTS implementation to gemini-3.8-flash-tts, and generation overall has been working well.

I haven’t yet rerun this exact 751-character passage that consistently returned PROHIBITED_CONTENT on 2.5. I’ll test the identical text on 3.8, without modifying the passage, and report back with the result.

If it does generate successfully on 3.8, would that indicate the false-positive behavior was specific to the older TTS classifier/model rather than the text itself?

4

Following up with additional findings from gemini-3.8-flash-tts.

I haven’t yet rerun the original 751-character passage from my initial report, so I can’t confirm whether that specific PROHIBITED_CONTENT rejection was resolved in 3.8.

However, I’m now encountering a similar and much more widespread problem with 3.8 using the Interactions API.

Recent results:

  • Chapter 18: So many passages were rejected that I had to repeatedly split the original narration segments into smaller pieces. The chapter ultimately expanded to 33 segments, and two still required device-voice fallback.
  • Chapter 19: The very first segment was rejected immediately on its first generation attempt with HTTP 400 and POLICY_BLOCK.
  • My application does not automatically retry policy-blocked passages. Each subsequent attempt is initiated manually.

Unlike the earlier 2.5 failure, which returned HTTP 200 with no audio and PROHIBITED_CONTENT, the newer model is returning an explicit HTTP 400 policy rejection.

I’m using the Interactions API with the transcript supplied as text and the voice instructions in speech_metadata. I’m not asking the model to generate new content, only to narrate existing text verbatim.

Repeatedly splitting passages is an inefficient workaround. It consumes additional requests, makes chapter generation substantially more difficult, and creates unnecessary audio boundaries.

Using a system voice is technically possible, but it’s not an acceptable long-term solution when the goal is consistent audiobook narration with the same character voices.

Could the Gemini team investigate whether the 3.8 TTS policy classifier is producing excessive false positives, particularly on longer fiction passages?

I’d also appreciate clarification on whether these HTTP 400 rejections are expected to behave differently from the earlier PROHIBITED_CONTENT errors.

I’ve added diagnostic tracking for the model, HTTP status, block reason, segment length, and repeated failures. I can provide those details for investigation without publicly posting additional copyrighted text.

Thank you for looking into this!

5

Another update: the blocking problem with gemini-3.8-flash-tts is continuing, and the number of rejected requests is becoming unreasonable.

I’ve now reached Chapter 19 of the audiobook I’m generating. My application tracks failed generations and subsequent splits by original passage.

Here are three examples from this single chapter:

  • Original passage 1: 8 recorded failures, 7 splits
  • Original passage 2: 4 recorded failures, 4 splits
  • Original passage 3: 3 recorded failures, 2 splits

These aren’t requests to generate new creative content. They’re attempts to narrate existing fiction verbatim, using the Interactions API.

Some of the rejected passages contain ordinary dialogue about camp, counselors, and ground rules. Nothing obvious in those excerpts explains the repeated policy rejections.

The model is returning HTTP 400 policy blocks. My application does not automatically retry rejected passages. I manually split them into smaller pieces, preserving the original wording.

This creates a cascading problem: one rejected passage becomes two requests, which can themselves be rejected and require further splitting.

The result is a substantial waste of API requests, significant manual intervention, and increasingly fragmented audiobook narration. With a Tier 1 limit of 100 requests per day, these repeated refusals make generating a complete book unnecessarily difficult.

Switching to a device/system voice is not a satisfactory solution when the purpose of using Gemini TTS is consistent, high-quality narration with specific character voices.

At this point, I’d really appreciate someone from the Gemini team investigating why the 3.8 TTS model is rejecting so many passages of otherwise ordinary fiction.

Is this a known issue with the Interactions API’s content filtering? Is there an intended fix or an estimated timeline for improvement?

I can provide additional diagnostic metadata, including HTTP codes, block reasons, segment lengths, and failure counts, if that would help the investigation.

6

Hello @Julie_David ,

Thanks for the detailed follow-up. We are looking into this issue. Could you share your Project ID, the timestamps or interaction IDs of a few blocked requests, and the exact passages, via direct message?

7

Thanks! I have the Project ID, timestamps, exact passages, and a full diagnostic packet ready, but I don’t have a Message/DM option on your profile. Could you please DM me first so I can reply privately with the requested information?