Free Tier Interactions API: GetModel succeeds, but generation returns 503 on Gemini 3.8 Flash and 429 on Gemini 3.6 Flash

Hello,

We are testing the Gemini Interactions API on a new Free Tier project with no billing account attached.

Model information lookup succeeds, but none of our generation attempts have succeeded. We would appreciate guidance on identifying the applicable quota or configuration issue.

Environment:

  • Node.js 24.18.0
  • @google/genai 2.29.0 for SDK tests
  • Node https.request for direct REST tests
  • Interactions API v1beta
  • An API key created in Google AI Studio, shown in Cloud as bound to a service account
  • API restriction: Gemini API
  • No application restriction
  • Synthetic text only; no personal or production data
  • No Files API

Direct REST request:

POST https://generativelanguage.googleapis.com/v1beta/interactions

{
  "model": "gemini-3.8-flash",
  "input": "Reply with exactly OK.",
  "store": false,
  "stream": false,
  "generation_config": {
    "max_output_tokens": 64
  }
}

The Gemini 3.6 Flash REST test used the same body with only the model changed to gemini-3.6-flash.

Each REST attempt used a 90-second timeout, no automatic retry, and exactly one outbound request. Separate attempts were manually authorized and executed; there was no automatic retry loop.

Results:

  1. Model lookup
  • gemini-3.8-flash: HTTP 200, 268 ms.
  1. Gemini 3.8 Flash SDK generation
  • Two attempts, with maxRetries: 0.
  • Both timed out after approximately 90 seconds.
  • No Google HTTP response, request ID, or token usage was captured.
  • The underlying cause remains unknown.
  1. Gemini 3.8 Flash direct REST generation
  • Two separate attempts returned HTTP 503.
  • Response times: 4,693 ms and 7,522 ms.
  • Error code: service_unavailable.
  • The error messages indicated temporary high demand for the model.
  1. Gemini 3.6 Flash direct REST generation
  • One attempt returned HTTP 429 in 996 ms.
  • Error code: too_many_requests.
  • Captured message:
    “Your project has exceeded a quota. See https://ai.dev/rate-limit to manage your rate limits.”

No generated text or token usage was returned by the REST attempts.

Unfortunately, the complete original 429 error details and response headers were not preserved. The quota metric/ID, RetryInfo, and Retry-After value are therefore unknown.

Timing and dashboard observations:

The diagnostic work took place during October 14–15, 2026, Korea Standard Time (UTC+9). Exact network transmission timestamps were not retained for every request.

The quota and rate-limit screens were checked after the failed requests, not at the exact time of transmission. The AI Studio dashboard had a 28-day period selected; we do not interpret the displayed values as totals for that entire period.

The AI Studio rate-limit view displayed:

Gemini 3.6 Flash:

  • RPM: 1 / 5
  • TPM: 5 / 250K
  • RPD: 1 / 20

Gemini 3.8 Flash:

  • RPM: 1 / 5
  • TPM: 488 / 250K
  • RPD: 2 / 20

A later Cloud quota view displayed daily request usage of:

  • Gemini 3.6 Flash: 1 / 20
  • Gemini 3.8 Flash: 3 / 20

These are post-request snapshots. Their collection times and metric definitions may differ. We are not using them to reconstruct individual requests or infer per-request token usage.

Cloud API metrics recorded HTTP 200, 429, 499, and 503 responses. The selected method metrics showed:

  • GetModel: 0% error rate
  • CreateInteraction: 100% error rate

We cannot establish a one-to-one relationship between the recorded HTTP 499 responses and the SDK timeouts.

The project has one Gemini API key. The user confirmed that the locally configured key matches the dedicated key in the project’s management screen. Available local records showed no evidence of scheduled generation calls, automatic retries, or duplicate traffic beyond the five generation attempts described above.

We are not assuming that the visible limits are the only applicable limits, that hidden traffic occurred, or that all failures share the same cause.

Questions:

  1. Is this Free Tier configuration supported for Interactions API generation with both models?

  2. Are there additional Interactions-specific, model-specific, or project-level quotas that are not represented in the standard RPM/TPM/RPD view?

  3. Can the exact quota metric or quota ID responsible for this past HTTP 429 be identified without reproducing the request?

  4. Is the described AI Studio-created, service-account-bound key configuration supported for Interactions API on the Free Tier?

  5. Are the Gemini 3.8 Flash 503 responses consistent with a known capacity issue, and is any additional project provisioning required?

Sanitized quota and API-metric screenshots can be provided if needed. Credentials, authentication headers, and project identifiers are intentionally omitted.

Official references:

Thank you.

Hi @TAEIN_WORKS, Here are the clarifications regarding the HTTP 503 and 429 errors on the Free Tier:

  1. HTTP 503 (Service Unavailable): On Gemini 3.8 Flash, 503 errors are due to our services being temporarily overloaded. Please see this pinned post for suggestions on how to handle this.

  2. HTTP 429 (Too Many Requests): We recently made some backend updates to ensure that all 429 errors come with a description field which properly explains the cause. We recommend scanning your logs for these. While a lot of pertinent information is currently available in the AI Studio Usage, Rate Limit & Billing pages, we’re working to make the cause of 429 errors easier to find in AI Studio. Please see below for advice on specific categories of 429 errors.
    Spend cap exceeded

    We return 429 errors if a spend cap is exceeded.

    Rate limits

    Multiple different types of rate limits can result in 429 errors. You should check the AI Studio Rate Limits page to see details of these. Notes:

    • Be sure to select the applicable project & time range.

    • Take special care to check the Search grounding & Map grounding limits further down the page

    • If you’re running into limitations from RPM or TPM limits, consider implementing backoff and retry with a long maximum delay (our SDKs support this through retry config).