FR: Wait for capacity

[mostperfectboy]

Currently when antigravity models are used too much, they hit capacity, giving up on that cred. This breaks agent flows when using just one account (or probably a low amount).

It would be nice if there was an option to either increase the retries/timeout or just keep retrying when within quota

[mirrobot-agent]

@mostperfectboy Thank you for submitting this issue. I am now beginning my analysis and will report back shortly.

[mirrobot-agent]

Initial Analysis Report

Summary: This is a valid feature request to add retry/wait behavior when antigravity models hit capacity limits, rather than immediately giving up on that credential.

Issue Validation: Confirmed

Reproducibility Assessment: Needs More Info (specific scenarios and error messages would help clarify the behavior)

Root Cause Analysis:

The current capacity handling behavior for Antigravity provider is as follows:

1. Quota/Capacity Errors: When an antigravity model hits capacity limits (HTTP 429 with RESOURCE_EXHAUSTED or QUOTA_EXHAUSTED), the error is classified as quota_exceeded in src/rotator_library/error_handler.py:640-646

2. Credential Rotation: The classified error triggers rotation to the next credential rather than waiting. In src/rotator_library/client.py, when a quota_exceeded error occurs:

   • The credential is marked as failed via usage_manager.record_failure()
   • The proxy rotates to the next available credential (lines 1166-1172)
   • The credential gets a cooldown based on the quota_reset_timestamp from the error response

3. No Wait-and-Retry Option: Currently, there is no mechanism to:

   • Wait for capacity to become available instead of rotating
   • Configure extended retries/timeout for capacity scenarios
   • Keep retrying on the same credential when within quota limits

4. Key Files Involved:

   • src/rotator_library/providers/antigravity_provider.py:614-771 - Quota error parsing with quota_reset_timestamp
   • src/rotator_library/error_handler.py:579-693 - Error classification logic
   • src/rotator_library/client.py:866-1598 - Retry and rotation logic
   • src/rotator_library/usage_manager.py:1596-1723 - Cooldown handling with quota_reset_ts

Suggested Labels:

• enhancement - This is a new feature request
• antigravity - Specific to the antigravity provider

Proposed Next Steps:

The implementation could add a configurable "wait for capacity" mode:

1. New Environment Variables:

   • ANTIGRAVITY_WAIT_FOR_CAPACITY=true|false - Enable waiting instead of rotating
   • ANTIGRAVITY_CAPACITY_WAIT_MAX_SECONDS=300 - Maximum time to wait for capacity

2. Implementation Options:

   Option A (Simple Wait): When capacity is exhausted and only one credential is available, wait for the quota_reset_timestamp before retrying the same credential.

   Option B (Wait with Polling): Periodically retry the request (with exponential backoff) until:

   • The request succeeds, or
   • The configured timeout is reached, or
   • A new quota error with a fresh reset timestamp is received

3. Code Changes Required:

   • Modify _execute_with_retry() and _streaming_acompletion_with_retry() in client.py
   • Add a new wait loop when classified_error.error_type == "quota_exceeded" and wait mode is enabled
   • Respect the retry_after value from the quota error for wait duration

Missing Information (if any):

• The specific error message/format seen when capacity is hit (to ensure proper detection)
• Whether you want to wait indefinitely when within quota, or have a configurable maximum wait time
• Whether this should apply globally or be configurable per-credential

---

This analysis was generated by an AI assistant.

[Rryvern]

Hello, I'm on Pro plan and today I use the proxy for manga translation. After some hour, I got an error like quota exceed (HTTP 429) even though I still have 50% quota left on my Antigravity app and unable to use any of the models at the moment. Is this normal or did Google have patch something recently?

[Mirrowel]

Hello, I'm on Pro plan and today I use the proxy for manga translation. After some hour, I got an error like quota exceed (HTTP 429) even though I still have 50% quota left on my Antigravity app and unable to use any of the models at the moment. Is this normal or did Google have patch something recently?

Antigravity is down for everyone. Nothing can be done.

Additionally for this FR: If 2 credentials fail with the bare 429 retries - the entire thing is down. I never had both fail when antigravity is not down.

UPD: Usually this is the case, but today this is not. This needs a fix.

[rendyuwu]

I’m seeing the same behavior here.

I have two Pro Antigravity credentials in the proxy, both can hit 429 via the proxy, but the same account works perfectly in the Antigravity IDE at the same time.

Is the proxy using a different endpoint or capacity pool than the IDE?
Or could API usage be subject to stricter capacity limits compared to IDE usage?

Clarification on this would help a lot.

[Mirrowel]

I’m seeing the same behavior here.

I have two Pro Antigravity credentials in the proxy, both can hit 429 via the proxy, but the same account works perfectly in the Antigravity IDE at the same time.

Is the proxy using a different endpoint or capacity pool than the IDE? Or could API usage be subject to stricter capacity limits compared to IDE usage?

Clarification on this would help a lot.

Unlike the usual antigravity going down - this seems like additional security was added. I already know of a possible fix, so i am testing them out.

[rendyuwu]

Thanks for the clarification, glad to hear you’re already investigating a possible fix.
Happy to test on my side if you need any additional data or feedback.

[Mirrowel]

I fixed it after doing some digging. There should be little impact on smart models. Though, gemini might get confused even more now.
For now, fix is only in the gemini cli quota PR, as i was literally in the middle of it when this happened. I will merge it to dev asap.

[Mirrowel]

Resolved in 96d5d21