What does the 429 error mean in Google Gemini CLI?

A 429 error means 'Too Many Requests'. Your usage has exceeded the rate limits set by Google for that specific model or API.

Why are my fallback Gemini models not working?

The primary model hitting a 429 error is incorrectly causing the entire Auth Profile to be marked as unavailable, preventing OpenClaw from even attempting to use your configured fallback models.

Can I use the same API key for multiple Gemini Auth Profiles?

Yes, you can. The suggestion is to create different named Auth Profiles in your OpenClaw config, each pointing to the same API key. This might help isolate rate limits to individual profiles/models.

Fix OpenClaw Gemini 429 Error: Auth Profile Cooldown Blocking Fallbacks

TL;DR — Quick Fix

Gemini 429 errors on one model are incorrectly locking the entire Auth Profile, preventing fallbacks; use a lighter model like gemini-2.5-flash-lite as default or manage auth profiles separately.

Run Diagnostics

Next Step

Fix now, then reduce repeat incidents

If this issue keeps coming back, validate your setup in Doctor first, then harden your config.

Open Doctor Harden Config

Error Signal

Cloud Code Assist API error (429): You have exhausted your capacity on this model. (rate_limit)No available auth profile for google-gemini-cli

What's Happening

You're hitting a 429 Quota Exhausted error with google-gemini-cli, specifically on a primary model like gemini-3-pro. Instead of just marking that single model as unavailable, OpenClaw's auth system is incorrectly locking the entire Auth Profile for that provider. This kills any fallback models you've configured in your chain, even if they have separate quotas or are unlimited. Your agent fails with "No available auth profile."

The Fix

The confirmed workaround is to adjust your model usage. One user found success by temporarily switching to gemini-2.5-flash-lite as the default model. This model has higher quotas (4m tpm, unlimited rpd). Use gemini-3-pro only for tasks that truly require its advanced capabilities.

Another approach, suggested but not confirmed, is to create multiple distinct Auth Profiles, even if they use the same underlying API key/token. Give them different names in your configuration. This might trick the system into treating them as separate entities, thus isolating cooldowns.

Example of separate auth profiles (conceptual):

auth:
  gemini_profile_1:
    provider: google-gemini-cli
    api_key: "YOUR_API_KEY"
  gemini_profile_2:
    provider: google-gemini-cli
    api_key: "YOUR_API_KEY"

providers:
  google_gemini_3_pro:
    auth_profile: gemini_profile_1
    model: gemini-3-pro-preview
  google_gemini_flash_lite:
    auth_profile: gemini_profile_2
    model: gemini-2.5-flash-lite

Why This Occurs

The google-gemini-cli provider or OpenClaw's rate-limiting logic incorrectly applies a cooldown to the entire Auth Profile when a model-specific 429 error occurs. It doesn't differentiate between model-level quotas and profile-level availability. Since Gemini often has granular quotas per model, this causes premature failure.

Prevention

Monitor your Gemini quotas: Keep a close eye on your usage for primary models. Understand which models have strict limits.
Strategic model selection: Use the most powerful (and potentially most rate-limited) models only when absolutely necessary. Leverage cheaper or unlimited models for simpler tasks.
Consider Auth Profile Separation: If you frequently hit limits on specific Gemini models, experiment with creating separate, named Auth Profiles for different models, even if they share an API key. This is the most promising structural workaround.

Discussion

This issue is actively being discussed and is currently unresolved in the OpenClaw GitHub repository.

openclaw/openclaw#13623

Last Updated: March 2026

Did this guide solve your problem?