Voice Replication returns 404 'Requested entity was not found' since Oct 1, 2026 (UI and API)

Gemini API
1

Voice Replication suddenly stopped working for an existing Gemini API workflow on October 1, 2026. Could the Gemini API team investigate CreateVoice and clarify whether there is a backend incident or a replication eligibility change?

Timeline (UTC)

  • Cloud Console CreateVoiceHttp metrics show HTTP 200 in the 5-minute bucket labelled 07:00 UTC on Oct 1.
  • The first recorded CreateVoiceHttp HTTP 404 appears in the bucket labelled 09:05 UTC on Oct 1. These are aggregated buckets, not exact individual-request timestamps.
  • Fresh terminal retest at 14:41 UTC on Oct 1 still returns 404 with and without voice.model (store=false).

Failure
POST https://generativelanguage.googleapis.com/v1beta/voices

{"error":{"code":404,"message":"Requested entity was not found.","status":"NOT_FOUND"}}

Model: gemini-3.8-flash-tts; voice type: replicated; normal workflow: store=false, with separate human reference and consent recordings.
SDK: google-genai 2.25.0, unchanged since September 28.

Also reproduced in Google’s UI
AI Studio > generate-speech > Create voice > Voice Replication fails with the same message using a freshly recorded browser sample and the mandatory consent phrase. The internal MakerSuiteService/CreateVoice RPC also returns 404. This was observed in two different projects under the same account.

What still works

  • GET /v1beta/voices: HTTP 200.
  • models.list: HTTP 200; gemini-3.8-flash-tts is visible.
  • Normal TTS generation with that model.

Already tested

  • voice.model as gemini-3.8-flash-tts, as models/gemini-3.8-flash-tts, and omitted: all 404.
  • Both store=false and store=true previously returned 404. The latest retest used only store=false.
  • Flash-Lite instead returns a specific 400 saying it does not support Voice Replication and to omit voice.model. This conflicts with the current Voice Replication guide, which lists both 3.8 TTS models.
  • Billing support confirmed active billing, with no suspension or restriction. Quotas are not exhausted. No incident was listed on the status pages when checked.

The published Gemini API guide still documents this endpoint/model. The Cloud Text-to-Speech page’s allowlist appears to cover the separate older Vertex AI EAP workflow; it is unclear whether any additional eligibility applies to Gemini API Voices.

Please clarify:

  1. Is there a known CreateVoice routing/backend regression?
  2. Have account, region, or billing eligibility requirements changed?
  3. Which non-sensitive request identifiers would help, and is there a private technical escalation channel?

This report contains no API keys, audio recordings, email addresses, project IDs, or billing account IDs. A general outage is not yet established.

Additional checks from Cloud Console

  • CreateVoice paid Tier 1 quota at inspection: 45/100 requests per day; minute quota 0/10.
  • The API is enabled and the existing test key is available and restricted to the Gemini API.
  • Available project audit logs show no configuration changes during 06:00–10:30 UTC. Later service/IAM changes occurred after the failure during the support investigation.
  • AI Studio GenerateContent logs do not include CreateVoice; the earlier 06:57 UTC log was speech generation. The successful voice-creation evidence above comes from the API metrics.
  • The latest two HTTP 404 responses provide no X-Request-ID, X-Goog-Request-ID, or X-Cloud-Trace-Context header. HTTP Date: Oct 1, 14:41:56 and 14:41:57 GMT.

Can the team check the default voice-creation model/resource and replication eligibility for this failure window?

2

Fresh comparison on Oct 1 at 15:02 UTC: ordinary TTS without replication succeeds using the same API key, google-genai 2.25.0 and gemini-3.8-flash-tts. A single interactions.create request with the prebuilt voice Kore returned a valid 1.68-second WAV (mono, 24 kHz, 16 bit). Immediately before that, both voices.create(store=false) variants (voice.model omitted / gemini-3.8-flash-tts) still returned 404 NOT_FOUND.

The replication requests already contain real WAV reference and consent recordings as base64, not just text or file paths. Their headers match the recommended format: mono, 24 kHz, 16 bit; durations 19.52 seconds and 9.344 seconds. No recordings are attached publicly.

This comparison narrows the failure to voice creation; it does not establish the specific backend or eligibility cause.

3

Additional investigation found an eligibility detail in Google’s official September 23 launch post: Gemini 3.8 Flash TTS and Gemini 3.8 Flash-Lite TTS . Its footnote says AI Studio Voice Replication is unavailable in Illinois, Texas, EEA, UK, Switzerland and India. The Gemini API Voice Replication guide does not explain this restriction. Could the team clarify whether it also applies to Developer API and whether eligibility depends on request location, Google Account associated country, or payments-profile country? This is a hypothesis, not a confirmed explanation of the 404.

At 15:20 UTC a direct REST POST with the documented minimal store=false payload and the same real WAV bytes also returned 404 NOT_FOUND, independently of the SDK voices method. The complete error JSON has only code/message/status, no details. Filtered lists were read correctly through response.voices with pagination checked: zero replicated and zero prompted stored voices, no next page. Target model metadata retrieval succeeds.

4

Thank Sebastian, we’re working on a fix.

5

Thank you, Jon. A fresh retest on October 1 around 15:42 UTC still returns 404 NOT_FOUND for both voices.create(store=false) variants (voice.model omitted and gemini-3.8-flash-tts). Model and voice listing continue to succeed. No configuration changes were made for this retest.

Is there an estimated rollout time for the fix, or anything affected developers need to change once it is deployed?

6

Retested on October 2 around 04:56 UTC: both voices.create(store=false) variants now succeed and return a voice key, with voice.model omitted and with gemini-3.8-flash-tts. This uses the same existing API access, SDK 2.25.0 and human reference/consent WAV files as the failing tests. No configuration changes were needed for this retest.

This confirms voice creation has recovered for our workflow; I have not run another speech-generation request in this test. Thank you for working on the fix. If possible, please share the cause or any prevention guidance.

7

Thanks for noting the fix Sebastian. I can confirm a fix was applied at our end. It was an internal configuration issue. I don’t expect it to be an issue in the future.