Skip to main content
The Nano Banana gateway access layer supports at least 5,000 API requests per minute and does not apply a fixed platform-side RPM limit to the documented generation and asynchronous-submission routes. This is a request-ingress capacity statement. It is not a promise that 5,000 images will finish each minute: image completion depends on model duration, request size, the selected upstream model, and official upstream capacity.

​
Public service contract

The 98% figure is an operational availability objective. It is not presented as measured historical uptime, a contractual SLA, or a service-credit commitment.

​
What 5,000 RPM means

​
Request acceptance is not image completion

RPM counts API requests reaching the gateway. A synchronous request can remain open while a model generates the image; an asynchronous request returns HTTP 202 after the task is accepted and completes later. Use the asynchronous task flow when work must survive the client connection or when a burst should be separated from image completion.

​
No fixed gateway cap does not remove upstream limits

The gateway does not impose a fixed public RPM ceiling on these routes. Google can still enforce model, project, RPM, images-per-minute, spend, or capacity limits. Other responses such as validation, authentication, balance, and ownership errors remain independent of rate limiting.

​
Interpret HTTP 429 as an upstream response

For the documented Nano Banana routes, HTTP 429 indicates that the official upstream provider could not accept the request under its current rate, quota, spend, or model-capacity conditions. When 429 occurs:
  1. Honor Retry-After when the response supplies it.
  2. Otherwise use exponential backoff with random jitter.
  3. Limit retry attempts or set a total deadline.
  4. Reduce burst concurrency while the upstream provider recovers.
  5. Do not retry 400, 401, or 403 as if they were rate limits.
Google documents 429 RESOURCE_EXHAUSTED for RPM, TPM, RPD, spend-based, project-tier, and model-capacity limits. See the Gemini API rate-limit documentation.

​
Availability objective

The API targets availability of 98% or higher. Applications that require continuous production should still plan for transient upstream 429 and 5xx responses, network timeouts, and model-specific capacity changes. A resilient client should keep request IDs, use bounded retries, persist asynchronous task_id values before returning control to the user, and avoid treating one provider response as a permanent failure.

​
Production integration checklist

  • Keep API keys and model IDs in configuration.
  • Apply a client-side concurrency ceiling that matches your own worker and budget limits.
  • Use asynchronous submission for work that cannot remain attached to one HTTP connection.
  • Honor Retry-After and use bounded backoff with jitter.
  • Record responseId, task_id, model ID, HTTP status, and request time for support.
  • Monitor your own completed-image rate separately from gateway RPM.
  • Review the error and retry guide before production rollout.

Handle API errors

Distinguish upstream 429 responses from validation, credentials, balance, and server failures.

Use asynchronous tasks

Accept work quickly, persist task IDs, and retrieve terminal results.

Implement bounded polling

Add Retry-After, jitter, a deadline, and terminal-state handling.
Last modified on September 2, 2026