Lyria 3.5 returns unexplained PROHIBITED_CONTENT for original fictional songs

Gemini API
1

We are evaluating lyria-3.5 through the Gemini API for original, fictional personalized songs.

Several requests returned HTTP 200 with:

promptFeedback.blockReason: PROHIBITED_CONTENT

No audio was generated, and the response did not include a detailed safety category or candidate finish reason. We are not asking to bypass a safety filter. We want to determine whether this represents a policy restriction, unsupported request formatting, or a possible false positive.

Endpoint:

POST https://generativelanguage.googleapis.com/v1beta/models/lyria-3.5:generateContent

Controlled observations:

  • Two byte-identical baseline requests generated approximately two-minute recordings successfully.
  • A timing-only variant using the same lyrics and directions, but requesting 180 seconds, was rejected in about 752 ms.
  • A format-only variant representing the same two-minute composition plan and lyrics was rejected in about 537 ms.
  • A full three-minute plan was rejected in about 650–726 ms.
  • Another controlled verse variant generated audio successfully.
  • Rejected responses contained no useful prompt or output safety-category details.
  • We did not automatically retry rejected requests.

All lyrics and scenarios were original fictional test material. The requests did not ask to imitate a living artist’s voice or reproduce copyrighted lyrics.

Could a Google team member clarify:

  1. Is PROHIBITED_CONTENT used only for content-policy enforcement, or can it also represent unsupported structure, formatting, or timing instructions?
  2. Is there a supported way to obtain the rejection category without exposing private lyrics publicly?
  3. What is the recommended format for supplying exact original lyrics, section-level musical directions, and requested durations of one, two, or three minutes?
  4. What evidence should we provide through a secure channel for a possible false-positive investigation?
  5. Are HTTP 200 prompt-block responses with no generated audio billable?

We retain sanitized request-body fingerprints and private accepted/rejected request pairs. We can provide the minimum necessary evidence privately to an authorized Google representative, but will not publish customer material, credentials, or full request bodies here.

2

Hello @Barry_Turner ,

To investigate more on this, could you please share: A minimal reproducible code with request payload via Direct Message?