[FEATURE] Big Improvements batch

[Naster17]

Hi! I have a couple of ideas on how improve this project.

• if I added multiple keys for the same providers so that the Models and Limits list in the main menu would also update, example I've added five Groq keys right now, but I still have 105M tokens on the main page just like when I had one groq API key

• I also noticed that the api endpoint /v1/models returns a list of all models, but it would be better if it gave a list of currently available models, those providers that I have already connected . This will make it easier and faster to choose from the models available to me now, rather than from all the models available in freellmapi.

• Not sure: "Automatic fallover — If the chosen provider returns a 429, 5xx, or times out, the router skips it, puts the key on a short cooldown, and retries on the next model in your fallback chain (up to 20 attempts)" I haven't tested this yet, but wouldn't it be better to switch to the next provider key? If there are more than one while the leading key is in cooldown.

• Opencode Zen, new free model available. They added a new free model MiniMax M3 can someone add it :)

[tashfeenahmed]

Thanks for the detailed list! Going through it point by point:

1. Multiple keys multiplying the token budget: declining this one. Each key only carries an independent quota if it comes from a separate account, and multi-accounting is against most providers' ToS. The README's rule of thumb is one account per provider, and the dashboard won't present account stacking as a supported mode. Same reasoning as the just-closed #240, see the note there. If your five Groq keys are from one account they share a quota anyway, so the current number is the honest one.

2. /v1/models should only list models you can actually reach: agreed. Today it lists every enabled catalog model even for providers you have no key for, which the router can never route to. Filtering by connected providers is the right behavior and matches what the dashboard already does for the budget bar. PR welcome if you want to take it (the query is in server/src/routes/proxy.ts, the /models handler), otherwise it's on the list.

3. Trying the next key while one is cooling down: already works that way. Cooldowns are per key, not per provider. The router tries every healthy key for a model before falling to the next model in the chain, and a cooled-down key is skipped while its siblings keep serving. If you see behavior that contradicts that, a request log would help and I'll dig in.

4. MiniMax M3 on OpenCode Zen: on its way. It's part of a catalog update currently being split out of #231 into its own PR.

Keeping this open for point 2.

[tashfeenahmed]

MiniMax M3 on OpenCode Zen is live as of #249 - model id minimax-m3-free, verified working with tool calling. Thanks for the recommendation, you're in the README contributors now!

One heads-up: Zen's docs don't list it in the free pricing table (same status qwen3.6-plus-free had before its promo ended with a "Free promotion has ended" error), so it's on our watchlist in case the promo rotates. Bonus from the same probe run: nemotron-3-ultra-free (the 550B) also landed - Zen serves it in ~2s with structured tool calls.

The other items in this issue (multi-key limit aggregation, /v1/models filtering by configured providers, key-level failover) are still open - keeping this issue up for those.

[Naster17]

Thank you, I was glad to help, I appreciate it ;)

[tashfeenahmed]

Going through this batch:

• Multiple keys multiplying the token budget — declined earlier (multi-accounting is against most providers' ToS; one account per provider).
• MiniMax M3 on OpenCode Zen — added in V24: Zen roster refresh - Nemotron 3 Ultra + MiniMax M3 free, pause hung NIM gemma #249.
• Switch to the next key while the leading key is in cooldown — already how the retry loop works: a 429 benches that model+key and the router advances to the next key/model in the chain.
• /v1/models should reflect what's actually available — done. Split into /v1/models: return the full catalog with per-model availability + opt-in filter #287 and shipped in feat(models): /v1/models returns full catalog with per-model availability (#287) #289: /v1/models now returns the full catalog by default, each model tagged available + unavailable_reason (no_key/disabled), with ?available=true to get just the connected ones.

Closing the batch issue — thanks @Naster17. Open a fresh issue for anything still outstanding.

[Naster17]

Ok, Nice work!