feat(auth): model-level rate limit locking for multi-bucket providers

[rothnic]

Summary

Adds model-level rate limit locking for providers with separate per-model quota buckets (e.g. Antigravity).

Closes #110

Problem

Antigravity (and Vertex AI) maintain independent quota buckets per model family — Claude models and Gemini models have separate rate limits under the same account. When 9router receives a 429 Too Many Requests for any model, it currently locks the entire account in the database, preventing access to all models including those with full quota remaining.

Example: A 429 on claude-opus (Account A) locks Account A entirely. Subsequent gemini-pro requests skip Account A and burn Account B's quota, even though Account A's Gemini bucket is 100% available.

Solution

In-memory model-aware locking that tracks rate limits per connectionId:model pair rather than per account.

How it works

1. On 429 (multi-bucket providers only): Instead of locking the account in the database, we set a temporary in-memory lock for that specific model (default 5 minutes or the calculated backoff duration).
2. On request: The connection filter checks both the standard account-level DB lock AND the in-memory model lock. If connectionId:model is locked, we skip that account for that model only — other models remain accessible.
3. Fallback behavior: When all accounts are model-locked for a specific model, returns a retryAfter response with a short 1-minute retry window (vs the standard account-level backoff).

Design decisions

• In-memory only — No database schema changes. Locks clear on restart. Low risk, zero migration.
• Provider-gated — Only enabled for providers in MULTI_BUCKET_PROVIDERS set (currently antigravity). Other providers use the existing account-level locking unchanged.
• Backward compatible — The model parameter defaults to null. When not provided (e.g. from combo handlers), behavior is identical to before.

Changes

File	Change
src/sse/services/auth.js	Add modelLocks Map, isModelLocked(), lockModel(), isMultiBucketProvider(). Update getProviderCredentials() and markAccountUnavailable() to accept model param and apply model-level filtering.
src/sse/handlers/chat.js	Pass model string to getProviderCredentials() and markAccountUnavailable() calls.

Testing

Validated in production with 2 Antigravity accounts serving mixed Claude/Gemini workloads. After applying this patch:

• Claude 429 on Account A only blocks Claude on Account A
• Gemini requests continue routing to Account A normally
• Standard account-level locking remains unchanged for non-Antigravity providers

Future work (from #110)

This PR implements the core locking mechanism. Potential follow-ups:

• Configuration: Add rateLimitScope: "model" | "account" to Provider settings in the dashboard
• Regex buckets: Allow defining model groups (e.g., ^claude-* = Bucket A) for more granular control
• Persisted state: Optionally store model locks in the database for persistence across restarts

[rothnic]

Ideally this would be stored in the database, but i wanted to avoid making too extreme of changes since I wasn't sure about any other preferred alternative approaches. This at least is a pretty simple and focused fix.

I did notice that some previous discussion seemed to think that antigravity is token limited, but from everything I've seen it is more request or prompt limited. Maybe could use some investigation whether that is true and if the available usage api could be leveraged in some way to have more intelligent fallbacks or routing. For example, i wouldn't mind being able to fallback from claude models to gemini model at some percentage of usage so i can retain some opus 4.6 usage for opencode's antigravity auth use.

[Wladefant]

GH Copilot is request based for sure. I was told that Antigravity work by analyzing work done, and seems like you have only a limited work done requests. But then some told that it is token based.

And I agree with you completely. A much smarter routing system is needed. that would always try to use the models up for 50 percent first and after that they can go to opus once again. And also of course the routing really needs to account the rollover time window, so that these models are used first that rollover earliest

[rothnic]

GH Copilot is request based for sure. I was told that Antigravity work by analyzing work done, and seems like you have only a limited work done requests. But then some told that it is token based.

And I agree with you completely. A much smarter routing system is needed. that would always try to use the models up for 50 percent first and after that they can go to opus once again. And also of course the routing really needs to account the rollover time window, so that these models are used first that rollover earliest

Sorry for the slow follow-up, ended up getting banned by antigravity, so i've been figuring out what the next best options are. From my understanding antigravity was request-based, but i could be misunderstanding. I thought it was N requests per 6 hours or something like that. Copilot it like 1200 requests per month, no hour-based timeout, but is only $40 and has free gpt-5-mini access.

At one point when i was having issues, i almost put litellm in front if 9router until i realized it wasn't going to help. It did kind of make me wonder if using something like litellm internally would be a good idea since you could kind of provide its configuration as an advanced mode.

I ended up grabbing a month of kimi for $40 for now until i have more time to figure out the next best option.

[Wladefant]

no way, all my accoutns are banned now from day to the other. That is crazy. Is there a way to fix this?

[rothnic]

no way, all my accoutns are banned now from day to the other. That is crazy. Is there a way to fix this?

Don't think so... there are a bunch of people that got banned over the past week or so. It was nice while it lasted.