Shouldn't there be a seperate activeIndex for each seperate quota instead of just being seperated by family?

[Stae24]

Pre-submission checklist

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

Feature description

I don't see reason to have the activeIndex for these seperate quotas grouped by family, there should be a seperate activeIndex for each seperate quota, so that accounts can be properly assigned for each model based on the quota for that specific model.

Use case

With the current implementation, you can have your gemini 3 pro being rate limited cause the activeIndex for all gemini models to shift, even when the other quotas (gemini 3 flash and gemini cli) haven't been rate limited.

Having a seperate activeIndex for each quota would stop this from happening.

Proposed implementation

Just simply have a seperate activeIndex for each seperate quota.

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!

This is a valid feature request for more granular account rotation. Currently, activeIndexByFamily only tracks two families (claude and gemini), meaning when any gemini quota (antigravity or CLI) is rate-limited on the current account, all gemini models rotate to the next account.

Your suggestion to track activeIndex per quota (e.g., separate indices for gemini-antigravity, gemini-cli, and potentially model-specific quotas like gemini-3-pro vs gemini-3-flash) would improve efficiency by allowing independent rotation. This way, rate-limiting on Gemini 3 Pro wouldn't unnecessarily rotate accounts for Gemini CLI requests that are still available on the current account.

This would require:

1. Expanding activeIndexByFamily to activeIndexByQuota in the storage schema
2. Updating AccountManager.currentAccountIndexByFamily to track per-quota indices
3. Ensuring backward compatibility with existing account storage

This is a reasonable enhancement that aligns with the plugin's multi-account rotation goals. PRs are welcome if you'd like to implement this, or it can be added to the roadmap for future development.

---

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

[NoeFabris]

Correction: Linked PR #388 partially addresses this by making Gemini account selection and wait behavior quota-style-aware (cli_first + fallback pools), but it does not implement separate active indexes per quota yet.