quota protection

[mingshi2333]

Pre-submission checklist

• I have searched existing issues and feature requests for duplicates
• I have read the README

Feature description

Currently, Google seems to have implemented a stricter anti-abuse mechanism. If an account repeatedly hits its usage quota limit (exhausts the quota completely), Google detects this behavior and penalizes the account by extending the refresh time for the next quota cycle.
This makes the current strategy of "using until empty" risky, as it jeopardizes the sustainability of the accounts.

Use case

The logic should be:

1. Monitor Usage: Track the usage percentage of the current account.
2. Threshold Trigger: Allow users to set a safety threshold (e.g., stop at 95% or leave a buffer of X requests).

Action: When the threshold is reached:

Auto-Switch: Automatically switch to the next available account/model.

Stop: If no other accounts are available, stop sending requests immediately to prevent hitting the hard limit.

Describe alternatives you've considered Manually monitoring usage, but this is inefficient and prone to human error.

Additional context Implementing this "soft limit" will protect accounts from being flagged for abuse and ensure the quota refresh times remain normal.

Proposed implementation

No response

Alternatives considered

No response

Compliance

• This feature is for personal development use
• This feature does not violate or circumvent Google's Terms of Service

Additional context

No response

[github-actions]

👋 Thanks for opening this issue!

Thanks for the request — I can reproduce the current behavior from the code: the plugin only knows an account is “out of quota” after the API returns a rate-limit/quota error (it parses QUOTA_EXHAUSTED / RATE_LIMIT_EXCEEDED and then marks the account as rate-limited with an escalating cooldown, up to ~2 hours). There is no code path that can read a “95% used” style quota percentage, because neither the Antigravity/Gemini responses nor this plugin currently expose a quota-usage endpoint/telemetry.

What you can do today to avoid burning a single account to 100%:

• Use an account selection strategy that spreads load instead of “sticky”. The plugin supports round-robin and hybrid strategies; hybrid already uses a token-bucket + health scoring model to prefer healthier accounts and avoid hammering one account.
• Add more accounts so rotation has somewhere to go when an account gets marked rate-limited.

What would need to change to implement a true “soft limit at 95%”:

• Because the plugin cannot query real quota percent, it would need a configurable estimated budget per account/model (requests or tokens) and stop/rotate once the estimate reaches a threshold.
• Alternatively, make the existing token-bucket parameters configurable (max tokens / refill rate) to enforce a conservative per-account cap (a practical “soft limit” even without quota telemetry).

Duplicate check: I don’t see an existing open issue/PR implementing pre-quota soft limits; related but not duplicates are #263 (accounts rate-limited) and #174 (retry loop when limited).

---

This is an automated response. A maintainer will review your issue soon.