Gemini API: Metadata 200 but generateContent returns 404/503 across multiple models

Gemini API
1

Hello Google AI Developers community,

We are investigating generation failures using synthetic prompts through the Gemini Developer API. No customer data was submitted.

The AI Studio project reviewed by the owner shows Free tier. Displayed peak usage was:

  • Gemini 3.6 Flash and 3.8 Flash: 1/5 RPM
  • Gemini 2.5 Flash: 0/5 RPM
  • Gemini 2.5 Flash-Lite: 0/10 RPM

Daily quota availability, legacy-model inference eligibility, and mapping between the tested key and the reviewed AI Studio project remain unverified. These RPM figures do not establish remaining quota or inference access.

Observed results:

  • gemini-3.8-flash: metadata HTTP 200; generation HTTP 503 (2.44 seconds)
  • gemini-3.8-flash: metadata HTTP 200; generation HTTP 503 (2.21 seconds)
  • gemini-3.6-flash: metadata HTTP 200; generation HTTP 503 (3.38 seconds)
  • gemini-2.5-flash: metadata HTTP 200, version 001; generation HTTP 404 / NOT_FOUND (400 ms)
  • gemini-2.5-flash-lite: metadata HTTP 200, version 001; generation HTTP 404 / NOT_FOUND (1.89 seconds)

For the 3.x diagnostics, response headers and error bodies completed normally, without a transport error or SDK deadline abort. The 3.x durations include metadata lookup; the 2.5 durations represent generation requests alone.

Client diagnostic completion timestamps:

  • 3.8 Flash: 2026-10-24T16:05:01.832Z
  • 3.6 Flash: 2026-10-24T16:18:18.519Z

Currently inspected environment: Windows; Node.js v24.22.0; @google/genai 2.30.0. Historical per-request runtime and SDK versions were not separately recorded.

Requests used:

  • Metadata: GET /v1beta/models for 3.x; GET /v1beta/models/{model} for 2.5.
  • Generation: POST /v1beta/models/{model}:generateContent.
  • 3.x: minimal JSON connection prompt, @google/genai, 45-second timeout, 2,048-token output cap, JSON response mode, temperature 0.2.
  • 2.5: direct REST, prompt ‘Reply with OK.’, 20-token output cap, 30-second timeout, redirects disabled; no custom temperature or structured-output configuration.
  • Exactly one generation attempt per approved test; automatic retries disabled.

Both 2.5 metadata responses advertised generateContent, countTokens, createCachedContent, and batchGenerateContent. Local mocks verified request paths and upstream error handling, but cannot establish live serving eligibility. No automatic model fallback was applied.

Could you clarify:

  1. Whether the 3.6/3.8 HTTP 503 errors reflect serving capacity or another project-specific availability issue.
  2. Whether our project is eligible for Gemini 2.5 inference, and whether restricted eligibility could explain metadata 200 followed by generation 404.
  3. Whether another API-version, model-resource, or API-key restriction requirement applies.
  4. Which safe diagnostic identifiers should be retained in separately authorized future tests.

Raw error messages, response headers, and Google-issued request IDs were not retained, limiting backend correlation. We are not claiming a confirmed account restriction or global service outage.

Please advise on a read-only eligibility check and the appropriate private escalation route. We do not want to change credentials, enable billing, or continue generation probes speculatively.

No API keys, passwords, authorization headers, local paths, or customer project contents are included in this report.

2

Hello @scubadude18,

  • 503 errors are temporary service overload, not a project restriction—enable retries with backoff per this pinned post.
  • Gemini 2.5 models are limited to projects with prior 2.5 usage—use gemini-3.5-flash-lite or gemini-3.8-flash, and view active limits in AI Studio (Rate limits).