Gemini API Rate Limits: Tier Quotas, 429 Handling, and Large-Payload Workflows

Requests per Minute, Tokens per Minute, and Daily Ceilings

The three rate limit dimensions serve distinct operational functions:

• Requests Per Minute (RPM) restricts network connection velocity. This boundary guards inference servers against connection floods and high-concurrency client loops.
• Tokens Per Minute (TPM) restricts total compute density. This threshold tallies all input tokens sent in the prompt plus generated output tokens. For long-context models, input token volume dominates consumption.
• Requests Per Day (RPD) limits total cumulative requests over a twenty-four hour period. This metric provides a hard budget ceiling on unpaid exploratory usage, resetting each day at midnight Pacific time.

Because Google evaluates every request against all active boundaries, an application can fail on TPM while staying well below its RPM ceiling. A single prompt carrying a few hundred thousand tokens can consume an entire minute's token allocation on a Free tier project, causing subsequent calls to fail until the rolling minute window elapses, even though the same project has used only one of its permitted requests.

Spend Caps and Rolling Rate Limits

For paid accounts, Google imposes rolling spend-based rate limits alongside RPM and TPM quotas. These spending thresholds evaluate across rolling ten-minute intervals to protect developer billing accounts against unexpected financial runaways caused by infinite loops or compromised credentials.

Google publishes these spend rate limits per usage tier, evaluated on a rolling ten-minute window: none on Free, $10 on Tier 1, $50 on Tier 2, and $200 on Tier 3. Whether they apply to a given account depends on its billing history and standing. If burst traffic consumes inference budget faster than the allowable velocity, the platform issues an HTTP 429 RESOURCE_EXHAUSTED response even when nominal RPM and TPM limits remain unreached. Upgrading through higher billing tiers expands these rolling windows, providing smoother capacity for high-throughput production services.

Free Tier Operational Constraints

The Free Tier provides a sandbox for evaluation, syntax experimentation, and small-scale automation. However, teams evaluating the Free Tier must account for specific operational trade-offs:

1. Stricter RPM and TPM Boundaries. Low token allocations prevent concurrent agent processing and large-file analysis.
2. Training Data Usage. Under Google terms of service for the Free Tier, prompt inputs and model outputs may be reviewed by human annotators and used to train Google products.
3. No Service Level Agreement. Production availability is not guaranteed on unpaid endpoints, and capacity can be dynamically throttled during regional peak hours.

For teams building commercial applications or handling private company files, linking a billing account to enter Tier 1 is necessary to ensure data privacy and establish reliable throughput.

Interactive Inference, Priority Inference, and Batch Processing

Google segments Gemini API traffic into distinct processing pathways, each carrying different rate limit behaviors:

• Interactive Traffic: Standard synchronous requests sent to the generateContent endpoint. These calls are metered directly against standard RPM and TPM quotas.
• Priority Inference: A dedicated routing option designed for mission-critical workloads requiring minimal latency variance. Priority consumption holds its own rate limits, documented as 0.3 times the standard rate limit for each model and tier, while still counting toward overall interactive traffic.
• Batch API: Asynchronous offline processing designed for bulk data jobs. Batch requests run asynchronously for bulk offline processing at a discounted rate, handling high-volume workloads without drawing down real-time interactive TPM allocations.

Implementing Exponential Backoff with Jitter

The first line of defense against transient 429 errors is an automated retry policy incorporating truncated exponential backoff and randomized jitter. Retrying immediately upon receiving an HTTP 429 error creates a cascading thundering herd condition that compounds server congestion.

Here is a resilient retry implementation in Python using standard libraries:

import time
import random
import requests

def call_gemini_with_backoff(url: str, payload: dict, headers: dict, max_retries: int = 5) -> dict:
    base_delay = 1.0
    max_delay = 32.0
    # Retry loop with exponential backoff
    for attempt in range(max_retries):
        response = requests.post(url, json=payload, headers=headers)
        # Check success
        if response.status_code == 200:
            return response.json()
        # Handle rate limiting
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            if retry_after:
                delay = float(retry_after)
            else:
                calculated_delay = min(max_delay, base_delay * (2 ** attempt))
                delay = random.uniform(0, calculated_delay)
            time.sleep(delay)
            continue
        # Terminate on non-rate-limit errors
        response.raise_for_status()
    # Fallback exception
    raise RuntimeError("Exceeded maximum retry attempts due to rate limits.")

Adding randomized jitter prevents synchronized worker threads from striking the API endpoint simultaneously on repeated intervals.

Client-Side Rate Limiting with Token Buckets

Reactive retries prevent crashes, but proactive rate limiting prevents 429 errors from occurring in the first place. In Node.js or TypeScript agent services, implementing a client-side token bucket or leaky bucket queue coordinates concurrent worker tasks before network transmission.

Here is a practical client-side rate limiter in TypeScript:

export class TokenBucketRateLimiter {
  private tokens: number;
  private lastRefill: number;
  private readonly capacity: number;
  private readonly refillRatePerSecond: number;
  // Initialize limiter
  constructor(capacity: number, refillRatePerSecond: number) {
    this.capacity = capacity;
    this.tokens = capacity;
    this.refillRatePerSecond = refillRatePerSecond;
    this.lastRefill = Date.now();
  }
  // Refill tokens
  private refill(): void {
    const now = Date.now();
    const elapsedSeconds = (now - this.lastRefill) / 1000;
    this.tokens = Math.min(this.capacity, this.tokens + elapsedSeconds * this.refillRatePerSecond);
    this.lastRefill = now;
  }
  // Acquire execution tokens
  async acquire(cost: number = 1): Promise<void> {
    while (true) {
      this.refill();
      if (this.tokens >= cost) {
        this.tokens -= cost;
        return;
      }
      const deficit = cost - this.tokens;
      const waitMs = Math.ceil((deficit / this.refillRatePerSecond) * 1000);
      await new Promise((resolve) => setTimeout(resolve, Math.max(50, waitMs)));
    }
  }
}

Integrating a token bucket limiter directly into your agent dispatch pipeline guarantees that outbound requests respect defined RPM constraints regardless of how many parallel agent tasks trigger simultaneously.

Why File Stuffing Fails at Scale

Many developer tutorials recommend uploading raw files directly into the Gemini Files API or converting documents into base64 strings embedded inside prompt payloads. While convenient for one-off scripts, this approach breaks down in autonomous workflows.

When multiple autonomous agents collaborate on a project, each agent requires access to specific factual excerpts. If every agent loads the complete source corpus into its context window, token consumption scales linearly with both corpus size and agent count. An agency running five specialist agents against a 500-page technical archive will consume millions of tokens per task cycle, producing constant 429 bottlenecks and unnecessary API expense.

Trade-Offs of Traditional Local Retrieval Systems

To mitigate context stuffing, engineering teams frequently attempt to build local vector database pipelines using open-source embedding models and local vector stores. While this architecture reduces prompt payload sizes, it introduces substantial infrastructure complexity:

• Document Chunking and Parsing: Engineering teams must build and maintain custom parsers for PDF layouts, slide decks, spreadsheet grids, and scanned images.
• Vector Database Operations: Managing standalone vector indexes requires operational overhead, cluster monitoring, memory tuning, and embedding synchronization.
• Synchronization Lag: When source files are updated by human collaborators, local vector databases fall out of sync unless custom polling daemons or webhooks are constructed.

Instead of building custom chunking and retrieval infrastructure from scratch, modern agent architectures decouple file persistence and semantic search into a dedicated workspace layer.

Configuring Gemini Agents with Fast.io MCP

Connecting an AI agent or custom Python script to Fast.io requires only configuring the remote MCP endpoint. Agents connect over Streamable HTTP at /mcp or legacy Server-Sent Events at /sse.

Here is an example MCP client configuration snippet:

{
  "mcpServers": {
    "fastio": {
      "url": "https://mcp.fast.io/mcp/key",
      "headers": {
        "Authorization": "Bearer YOUR_FASTIO_API_KEY"
      }
    }
  }
}

When an agent needs to answer an inquiry regarding a company policy or technical specification, it issues a search query against the workspace. The MCP server returns precise, citation-backed snippets that the agent inserts into its Gemini prompt. The resulting payload stays exceptionally small, eliminating rate limit throttling.