Fix Gemini API Timeouts: SDK Units, Model IDs and Proxy Limits

What I checked, and how

I read the source of two releases of the Python SDK (google-genai 1.39.1 and 2.29.0), ran the SDK's own timeout helpers offline, called the Gemini API with a free-tier key on 9 October 2026 to measure latency and check model IDs, and read the AWS and nginx documentation for the proxy defaults. I could not run anything on Gemini 3.1 Pro, because the free tier has a quota of zero for it (the 429 message says limit: 0 for requests and for input tokens). The latency numbers below therefore come from gemini-3.5-flash, and nothing here is a measurement of Pro.

The timeout unit: 600 is 0.6 seconds

In both SDK releases the field description reads "Timeout for the request in milliseconds", and the default is None, so there is no 60-second SDK default to raise. The SDK code that converts the value says the same: it divides by 1000 before handing it to the HTTP client. I ran the conversion helpers directly:

timeout=600.0    -> client waits 0.6 s,   header {'X-Server-Timeout': '1'}
timeout=600000   -> client waits 600.0 s, header {'X-Server-Timeout': '600'}

So a snippet that passes {'timeout': 600.0} and promises ten minutes gives you a client that gives up after 0.6 seconds and tells the server it will wait one second. If you suddenly see timeouts on every large call after "raising" the timeout, check the unit first. The corrected setup:

from google import genai
from google.genai import types

# timeout is in MILLISECONDS: 600_000 = 10 minutes
client = genai.Client(http_options=types.HttpOptions(timeout=600_000))

for chunk in client.models.generate_content_stream(
    model="gemini-3.1-pro-preview",  # "gemini-3.1-pro" returned HTTP 404
    contents=long_prompt,
):
    print(chunk.text or "", end="")

I verified that the client accepts these options and that generate_content_stream exists; I did not run this exact call against Pro, for the quota reason above.

There is no gRPC switch

I searched both SDK releases for a gRPC transport. The only mention of gRPC is in the description of an error type; there is no module, option or environment variable that changes the transport. If you read advice to "force gRPC" for the Gemini API in this SDK, there is nothing to set. Long calls are better served by streaming and by correct timeouts along the network path.

Model IDs and the free tier

A model-info request for gemini-3.1-pro returned 404 "Model is not found", while gemini-3.1-pro-preview exists. A generation request to the preview model on a free-tier key returned HTTP 429 with limit: 0 on both the request count and the daily input-token count. So a 429 on this model is not rate limiting that will clear; the free tier simply has no allowance for it. Another model, gemini-2.5-flash, answered "no longer available to new users" in the same session. Check the model list for your key before you debug timeouts.

How long large prompts took

I streamed a request to gemini-3.5-flash built from real README text and noted when the first text arrived. The model also spends tokens on internal reasoning, which counts toward the output cap.

Two points from this. The same 42,000-token prompt took 18 s in one run and under 5 s in another, and the two runs also differed in the output cap, so I cannot say what caused the gap; plan for variation instead of one fixed number. And the largest request did not time out: it failed with a 503 that no timeout setting would have helped. Retrying 503 with backoff belongs in the same fix list as raising timeouts.

Proxies and gateways cut the connection first

The limits in front of the API are often lower than the SDK's. From the vendors' documentation:

Two corrections to common advice follow from this. The 29-second API Gateway limit is a default that can be raised for Regional and private REST APIs, not a hard wall. And because the ALB and nginx timers measure silence, a streamed response that keeps sending data does not hit them the way a silent, buffered call does. nginx has proxy_buffering on by default, so if you stream through it, check that your chunks are not being held back; I did not test that.

What to do

1. Set the timeout in milliseconds on the client, and make it longer than the slowest call you expect.
2. Use the right model ID and confirm your key has quota for it; a 404 or a 429 with limit: 0 is not a timeout.
3. Stream long calls so that proxies see traffic, and raise the idle timeouts of every hop to at least the slowest expected first-byte time.
4. Retry 503 with backoff, and keep a fallback model for requests that must answer.
5. Cache large static context only on a paid tier: on the free tier, creating an explicit cache returned 429 in my prompt-caching test.

What I did not test

I did not call Gemini 3.1 Pro, run requests through a real ALB, API Gateway or nginx, measure the Node.js SDK, or time Vertex AI. The proxy values are quoted from the vendors' documentation as of the date above and may change.

Sources and Further Reading

• google-genai on PyPI — SDK releases 1.39.1 and 2.29.0 inspected
• Edit attributes for your Application Load Balancer — AWS
• Quotas for configuring and running a REST API in API Gateway — AWS
• ngx_http_proxy_module — nginx
• Rate limits — Google AI for Developers