Google AI for Developers Rate Limits: Diagnose API Errors

Google AI APIs enforce rate limits to protect service quality. When your application exceeds a limit, the API returns an error rather than processing the request. The error response tells you which limit was hit. Reading it correctly is the first step to choosing the right fix, whether that is a retry delay, a request restructure, or a quota increase request.

Rate limit investigations are the kind of troubleshooting that benefits from a record. The constraint you found, the workaround you tested, and the limit you agreed to stay within all affect future development sessions. Tools like fenbs keep those results in a project record that every future session reads. The Google AI tools overview covers the broader Google AI product landscape.

Types of rate limits in Google AI APIs

Google AI APIs apply several kinds of limits. Understanding which kind was hit determines the right response.

• Requests per minute (RPM): the number of API calls in a rolling 60-second window.
• Tokens per minute (TPM): the total input and output tokens across all requests in a minute.
• Requests per day (RPD): a daily cap on total requests, separate from the per-minute limit.
• Concurrent requests: the number of requests in flight at the same time.

Free-tier limits are lower than paid limits on most Google AI APIs. Check the Google AI for Developers documentation for current limits by tier and model. The numbers change; verify them on the official quota page rather than relying on a documentation article that may be outdated.

Reading the error response

When a rate limit is exceeded, the API returns an HTTP 429 status code with a JSON error body. The body includes an error message that names the specific quota that was exceeded. Read the message field before deciding what to do. A response that says you exceeded requests per minute calls for a different fix than one that says you exceeded daily tokens.

{
  "error": {
    "code": 429,
    "message": "Resource has been exhausted (e.g. check quota).",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Google AI APIs also return a Retry-After header in some cases. When present, it tells you how many seconds to wait before retrying. Respect it rather than retrying immediately. Immediate retries on a rate-limited endpoint increase the error rate without increasing the success rate.

Retry strategies

Exponential backoff is the standard retry strategy for rate limit errors. Wait a short time before the first retry, then double the wait on each subsequent failure, up to a maximum. Add a small random jitter to each wait to avoid synchronized retries from multiple clients hitting the API at the same moment.

import time
import random

def call_with_retry(fn, max_retries=5):
    wait = 1.0
    for attempt in range(max_retries):
        try:
            return fn()
        except RateLimitError:
            if attempt == max_retries - 1:
                raise
            jitter = random.uniform(0, 0.5)
            time.sleep(wait + jitter)
            wait = min(wait * 2, 60)

Do not retry on errors other than 429 and 503 without investigating. A 400 bad request error will not succeed on retry. A 401 unauthorized error needs a credential fix. Retry logic should be specific about which status codes it handles.

Restructuring requests to stay within limits

If retries alone do not solve the problem, restructure the workload. Batch requests that do not need to be parallel. Add a delay between requests. Reduce the token volume per request by trimming context to what the task actually requires.

For high-volume workloads, consider whether every request needs the same model. A task that produces many similar short completions may be better served by a smaller, cheaper model with higher limits than the flagship model with lower free-tier limits. Check the quotas for each model in the documentation.

For workloads that regularly approach free-tier limits, evaluate whether a paid tier is the right solution. Calculate the cost at your expected request volume and compare it against the cost of the engineering work needed to stay within free limits. The solo developer AI coding agents guide covers similar tradeoffs for independent developers.

Requesting a quota increase

Google AI for Developers provides a quota increase request form in the Google Cloud console. To make a useful request, document the specific quota you are hitting, your current usage, and the volume you need to support. A request with supporting data is more likely to be approved than a request for a round number.

Quota increases may take days to process. Plan for the delay before it becomes a production blocker. Test the increased limit when it is granted rather than assuming it took effect.

Recording constraints for the next session

Rate limit investigations produce facts that future development sessions need to know. The specific limit that applies to your tier and model. The retry strategy that was implemented. The request volume constraint the team agreed to stay within. These facts change how new features should be designed.

A session that does not know about the 60 RPM limit may design a feature that fans out to 200 parallel requests. A session that knows about it designs with batching and backoff from the start. The constraint in the record prevents the design problem.

How to do this with fenbs

1. Create a free account. Add a project for the Google AI integration with the current tier, model, and API limits as context.
2. When you hit a rate limit, record the error response and the investigation results as a lesson in fenbs: the limit type, the trigger, the retry strategy tested, and the outcome.
3. Record the agreed API constraints in Decisions and rules: the RPM limit for the current tier, the max concurrent requests, the retry strategy the codebase uses.
4. Connect your assistant over MCP from Integrations. Ask it to read the project context at the start of each session so it knows the constraints before it designs new features.
5. Update the constraints in the record when you move to a different tier or when a quota increase is granted. The record should always reflect the current limits.