What Are Google AI Studio's Free Tier Limits and Rate Limits in 2026

Mar 23, 2026

Purpose

I was building a side project using Google AI Studio’s free tier, and I needed to understand exactly what limits I was working with. The documentation is scattered, and community reports suggest things are changing. I needed clear answers: how many requests can I make? What happens when I hit a limit? Will my app break in production?

This post explains the rate limit types, current free tier quotas by model, and how to handle limits gracefully in your code.

Rate Limit Types Explained

Google AI Studio enforces three main types of rate limits on the free tier:

RPM (Requests Per Minute) - How many API calls you can make in a 60-second window. This is the most common limit you’ll hit during development when testing multiple calls in quick succession.

TPM (Tokens Per Minute) - The total number of input and output tokens processed per minute. This matters when you’re sending large prompts or getting long responses. A single request with a 50,000-token prompt could consume most of your TPM budget.

RPD (Requests Per Day) - The total number of requests allowed in a 24-hour period. Once you hit this, you’re done until the quota resets.

When I first started, I didn’t realize these limits compound. You can hit TPM before RPM if your prompts are large enough, or RPM before TPM if you’re making many small requests.

Current Free Tier Limits

I tested the limits and checked the official documentation. Here’s what I found for the main Gemini models available through Google AI Studio:

| Model           | RPM  | TPM     | RPD   |
|-----------------|------|---------|-------|
| Gemini 1.5 Flash| 15   | 1M      | 1,500 |
| Gemini 1.5 Pro  | 2    | 32K     | 50    |
| Gemini 2.0 Flash | 15  | 1M      | 1,500 |
| Gemini 2.0 Pro   | 2    | 32K     | 50    |

The Flash models are generous. I could prototype and test without constantly hitting walls. The Pro models are more restricted, which makes sense given their higher computational requirements.

But when I checked my actual usage in the AI Studio dashboard, I noticed my effective limits sometimes differed. Google appears to adjust these based on account age, verification status, and possibly other factors they don’t disclose.

To check your current limits, I used the API directly:

import google.generativeai as genai

genai.configure(api_key="YOUR_API_KEY")

# List available models and their limits
for model in genai.list_models():
    if 'generateContent' in model.supported_generation_methods:
        print(f"Model: {model.name}")
        print(f"  RPM: {model.rpm}")
        print(f"  TPM: {model.tpm}")
        print(f"  RPD: {model.rpd}")

This gave me the authoritative limits for my account at that moment.

How to Handle Rate Limits

I learned this the hard way: unhandled rate limits crash apps. Here’s how I handle them now.

First, I wrap all API calls in a retry mechanism:

import google.generativeai as genai
import time
from functools import wraps

def retry_on_rate_limit(max_retries=5, base_delay=1):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            retries = 0
            while retries < max_retries:
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if "429" in str(e) or "quota" in str(e).lower():
                        delay = base_delay * (2 ** retries)
                        print(f"Rate limited. Waiting {delay}s before retry...")
                        time.sleep(delay)
                        retries += 1
                    else:
                        raise
            raise Exception(f"Max retries ({max_retries}) exceeded")
        return wrapper
    return decorator

@retry_on_rate_limit(max_retries=5, base_delay=2)
def generate_content(model, prompt):
    return model.generate_content(prompt)

But the better approach is proactive monitoring. I track my usage to avoid hitting limits entirely:

import google.generativeai as genai
from datetime import datetime, timedelta
import threading

class UsageTracker:
    def __init__(self, rpm_limit=15, tpm_limit=1_000_000):
        self.rpm_limit = rpm_limit
        self.tpm_limit = tpm_limit
        self.requests = []
        self.tokens = []
        self.lock = threading.Lock()

    def can_make_request(self, estimated_tokens=0):
        now = datetime.now()
        minute_ago = now - timedelta(minutes=1)

        with self.lock:
            # Clean old entries
            self.requests = [t for t in self.requests if t > minute_ago]
            self.tokens = [(t, cnt) for t, cnt in self.tokens if t > minute_ago]

            current_rpm = len(self.requests)
            current_tpm = sum(cnt for _, cnt in self.tokens)

            if current_rpm >= self.rpm_limit:
                return False, f"RPM limit reached: {current_rpm}/{self.rpm_limit}"
            if current_tpm + estimated_tokens > self.tpm_limit:
                return False, f"TPM limit would be exceeded: {current_tpm + estimated_tokens}/{self.tpm_limit}"

            return True, "OK"

    def record_request(self, tokens_used):
        now = datetime.now()
        with self.lock:
            self.requests.append(now)
            self.tokens.append((now, tokens_used))

# Usage
tracker = UsageTracker(rpm_limit=15, tpm_limit=1_000_000)

def safe_generate(model, prompt, estimated_tokens=1000):
    can_proceed, message = tracker.can_make_request(estimated_tokens)
    if not can_proceed:
        raise Exception(f"Cannot proceed: {message}")

    response = model.generate_content(prompt)
    tracker.record_request(response.usage_metadata.total_token_count)
    return response

This approach lets me fail fast before making the API call, rather than waiting for Google to reject me.

For JavaScript/Node.js projects, the pattern is similar:

class RateLimiter {
  constructor(rpmLimit = 15) {
    this.rpmLimit = rpmLimit;
    this.requests = [];
  }

  async waitForSlot() {
    const now = Date.now();
    const oneMinuteAgo = now - 60000;

    this.requests = this.requests.filter(time => time > oneMinuteAgo);

    if (this.requests.length >= this.rpmLimit) {
      const oldestRequest = Math.min(...this.requests);
      const waitTime = oldestRequest + 60000 - now + 100;

      console.log(`Rate limit reached. Waiting ${Math.round(waitTime/1000)}s...`);
      await new Promise(resolve => setTimeout(resolve, waitTime));
      return this.waitForSlot();
    }

    this.requests.push(Date.now());
  }
}

// Usage with Google Generative AI
const { GoogleGenerativeAI } = require("@google/generative-ai");

const limiter = new RateLimiter(15);
const genAI = new GoogleGenerativeAI(process.env.GOOGLE_API_KEY);

async function safeGenerate(prompt) {
  await limiter.waitForSlot();
  const model = genAI.getGenerativeModel({ model: "gemini-1.5-flash" });
  return await model.generateContent(prompt);
}

Community Reports on Changes

Here’s where things get concerning. I saw a Reddit post titled “Google AI Studio is GOATED” that sparked discussion about upcoming changes.

The original poster praised AI Studio’s free tier for app building. But a comment with 5 upvotes stated: “Yep, and it’s getting significantly nerfed on April 1st for the free tier.”

Another user asked for clarification: “Wait, I thought everyone was waiting on AI Studio because it got nerfed and the daily limits were massively reduced? Is all that fixed again?”

The thread suggests Google has already made changes to free tier limits, and more changes may be coming. The 95 upvotes on the original post indicate strong developer interest in this topic.

My takeaway: don’t build critical infrastructure assuming current free tier limits will persist. Google has changed them before and may change them again.

I recommend:

Monitor the official pricing page at ai.google.dev/pricing for announcements
Set up alerts for rate limit errors in your application
Have a paid tier fallback if your app needs guaranteed availability
Subscribe to relevant communities like r/GoogleGeminiAI for early warning of changes

Summary

Google AI Studio’s free tier offers generous limits for prototyping and personal projects. Flash models get approximately 15 RPM, 1M TPM, and 1,500 RPD. Pro models are more restricted at around 2 RPM and 32K TPM.

The key to using these limits effectively is proactive monitoring and graceful handling. Don’t wait for 429 errors to crash your app. Track your usage, implement retries with exponential backoff, and fail gracefully when limits are reached.

Most importantly, stay informed. Community reports suggest free tier limits may change, and relying solely on the free tier for production applications carries risk. Always verify current limits on the official Google AI documentation.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!