The Gemini API's daily request quota resets at midnight Pacific Time. That is usually 3 a.m. in New York. But an AI Studio “rate limit” message does not, by itself, tell you that you have exhausted this daily quota. A short burst of requests, too much input per minute, or a billing restriction can also prevent another response.
Start by identifying the product, project, model, and limiting metric. Then use the relevant reset rule. Google's rate-limit documentation specifies the midnight reset for requests per day (RPD); it does not promise that every AI Studio warning disappears at that time.
Find the limit behind the message
If you are in Google AI Studio, note the selected model and whether the feature is using a paid API key. If you are calling the Gemini Developer API from code, identify the project that owns your key. These details should match the project and model you inspect in AI Studio's active rate limits.
If you are using Gemini Apps, such as the personal chat experience at gemini.google.com, use that product's limits help. Its subscription and replenishment rules do not establish your Gemini API quota. Likewise, a Vertex AI request needs Vertex AI quota documentation rather than a Developer API allowance copied into its configuration.
For an API failure, save the HTTP status, full error message, timestamp with time zone, model ID, and any quota details. 429 RESOURCE_EXHAUSTED is a starting point for diagnosis. If the response names the exhausted metric or supplies a retry delay, use it; neither detailed quota fields nor a Retry-After header should be assumed to appear in every response. Keep API keys out of screenshots and support posts.
| What you find | What it measures | Useful next step |
|---|---|---|
| RPM, requests per minute | Request frequency | Slow the queue and reduce simultaneous requests; retry with a bounded delay. |
| TPM, input tokens per minute | Input sent across requests | Send less context or fewer requests per minute. |
| RPD, requests per day | Daily request count | Wait for midnight Pacific, or check a suitable paid tier if sustained capacity is the problem. |
| IPM or TPD | A model-specific image or daily token limit | Read that model's active limit and error details; do not substitute the RPD rule. |
| Spend-based rate limit | Cost within a rolling 10-minute window, where applicable | Reduce expensive requests and allow recent spending to move out of the window. |
| Context-length error | The size of one request or conversation | Remove unnecessary history or attachments, or use a suitable model. |
| Billing action required or no credits | Whether paid service can run | Inspect billing status; a daily request reset cannot fund a depleted account. |
The official definitions count input toward TPM, not input plus generated output. Different models expose different limits, and exceeding any applicable limit can stop a request even when the others have room. There is no universal free-tier or paid-tier quota table that reliably describes every current project.
When the daily reset happens
For Gemini Developer API RPD, the day changes at 00:00 in America/Los_Angeles. Pacific Time alternates between PST (UTC−8) and PDT (UTC−7). Use a named time zone rather than treating “Pacific” as a fixed UTC offset.
For example, the reset on September 6, 2026 occurs at:
| Location | Local reset time on that date |
|---|---|
| Los Angeles | 12:00 a.m. PDT |
| New York | 3:00 a.m. EDT |
| UTC | 07:00 |
New York is usually three hours ahead, but scheduling software should still convert the target date with time-zone rules, especially around daylight-saving transitions. A daily reset is tied to the Pacific calendar day, not 24 hours after your first request or the moment the error appeared.
An exhausted RPM or TPM allowance has a different response: reduce short-term traffic and allow time before another attempt. Do not wait until midnight solely because the error says 429. Conversely, repeatedly waiting a few seconds will not restore a daily allowance that is already exhausted. Google does not document a token-bucket implementation or guarantee that all minute quotas reset at the start of each clock minute.
A daily reset also does not reserve the renewed capacity for your next browser action. Another application using the same project can consume it. If the first attempt after midnight fails, inspect the new error rather than concluding that the reset never happened.
If AI Studio still refuses requests after waiting
Work through these checks in order so each observation changes what you do next.
- Match the project and model. Check the key's project, the model actually requested, and the active limits for that combination. A paid project elsewhere in your account does not establish the tier of the key currently in use.
- Read the limiting metric again. A daily quota can renew while a burst immediately hits RPM or TPM. If the limit itself is zero or the model is unavailable to the project, treat this as an access or configuration question until you establish that a reset applies.
- Account for other callers. Local scripts, deployed applications, colleagues, and other keys in the same project share the project quota. Pause unnecessary callers before trying one small request.
- Inspect billing status if this is paid usage. Look for an incomplete setup, a required billing action, or exhausted Prepay credits. A positive balance alone does not mean the account has remaining request or spending capacity.
- Escalate with a reproducible description. If the matching project shows available capacity and requests still fail, record the error before and after waiting, model ID, time zone, tier, and a minimal request without credentials. Check Google's troubleshooting guide and its linked service status before posting to developer support.
For Prepay accounts, Google says a zero balance stops API keys across projects linked to that billing account. Service does not automatically fall back to the free tier. Billing charts may also lag, so use the account's current status and balance rather than treating an empty chart as proof that no usage occurred. See Gemini API billing.
Google AI Studio is generally free to use, but paid features used with a paid project's API key can incur that key's charges. Linking billing is therefore a capacity and cost decision, not a guaranteed fix for every Studio message. Confirm the key, project, and model before making another paid attempt.
What a tier upgrade actually changes
A higher tier can provide higher active limits. It does not remove every limit, guarantee available serving capacity, or change which project a key belongs to. Preview and experimental models may have tighter limits.
As checked on September 6, 2026, Google's tier requirements are:
| Tier | Qualification |
|---|---|
| Tier 1 | Set up and link an active billing account. Complete the billing setup required for your account. |
| Tier 2 | At least USD $100 paid, plus 3 days since the first successful payment. |
| Tier 3 | At least USD $1,000 paid, plus 30 days since the first successful payment. |
For Tiers 2 and 3, qualifying cumulative spending covers Google Cloud services on the billing account linked to the project, not only Gemini API usage. A stored payment method or an unbilled usage estimate is not the same as a successful payment. Check the project's displayed tier after qualifying; Google says upgrades are generally automatic, with subsequent tier changes taking effect within 10 minutes. Approval and additional rate-limit increases are not guaranteed.
There is also a separate spend-based rate limit for accounts to which it applies, depending on billing history and account standing. The documented limits per rolling 10 minutes are USD $10 for Tier 1, $50 for Tier 2, and $200 for Tier 3. These are neither a daily quota nor a monthly budget. An expensive burst can hit this restriction while RPM and TPM still look acceptable. Shorter inputs, shorter outputs, or a lower rate of expensive requests can help in this case.
Keep retries from becoming another burst
Retrying is useful when the problem is temporary. It is wasteful when the error establishes a depleted daily allowance, an unavailable model, or a billing problem.
For transient rate pressure, use bounded exponential backoff with jitter: spread retry times, increase delays after repeated failures, and stop when the request's retry count or time budget is exhausted. Honor a server-provided delay when present. Check whether your SDK already retries before adding a second retry loop; multiplying the two can produce far more attempts than expected.
A practical application policy is to queue a request once, give transient failures a small finite retry budget, then return a recoverable error or defer the job. If the daily quota is exhausted, pause that work until the applicable reset instead. Do not blindly retry 400 or 403 errors; their request or access problem needs investigation. A 503 can be temporary serving pressure and also warrants bounded retries. Google's error guidance distinguishes these statuses.
For detailed error-specific investigation, continue with diagnosing Gemini API 429 RESOURCE_EXHAUSTED.
Plan throughput against the limit you actually hit
Build a small capacity estimate from your project's active limits and your own input sizes. Use it to choose queue speed, rather than copying an old model table.
Illustrative example, not a Google quota: suppose a project shows 60 RPM, 120,000 input TPM, and 1,000 RPD. If each request sends about 4,000 input tokens, TPM allows roughly 30 requests per minute before leaving any headroom. Running at the nominal 60 RPM would exceed the input allowance. Meanwhile, spreading 1,000 requests evenly across an eight-hour workday permits only about 2.1 requests per minute on average. The daily limit can dominate sustained work even when short bursts succeed.
This arithmetic is a planning estimate, not a promise that a particular burst will be accepted. Leave headroom for variation and coordinate workers across the project.
Use Google's token-counting tools on representative inputs. Long conversation histories and attachments can increase input size, so measure the complete request rather than only the latest question. A new chat may reduce that input; it does not replenish project RPD.
Choose an optimization that matches the bottleneck: queue and pace calls for RPM, trim unnecessary input for TPM, and avoid redundant calls for RPD. An application response cache can prevent a repeat request when reuse is appropriate. Cache keys should account for the model, settings, and relevant input, with user data kept appropriately separated. This is different from clearing your browser cache, which does not restore server-side quota.
For noninteractive work, evaluate the Batch API's separate limits rather than assuming that combining many tasks grants extra standard-request capacity. Changing models also requires checking the new model's limits and whether it still performs the task adequately.
Can a new key or a Gemini subscription reset the quota?
A new API key in the same project does not add quota. Keys share the project's limits. Rotate a key for credential management, not as a recovery step for exhausted capacity.
A Gemini Apps subscription is not an API tier upgrade. Use the API project's billing and active-limit information to decide whether an upgrade is relevant. If you only use Gemini Apps, follow its own displayed limit and reset information.
A context counter is not a daily token balance. It helps describe what a model must process in that conversation. If the chat is too large, reduce its input. If the error names RPD, preserve the conversation if you need it and address the project's daily request allowance instead.
