feat: multi-key round-robin per provider (C5)#14
Merged
Conversation
Lets a provider hold a pool of API keys and rotates across them per request, so free-tier users can spread load over several keys instead of hammering one key's limit. (Closes the round-robin gap from the v0.1.x audit.) What changed - Config: providers accept `apiKeyEnvs` (an array) alongside `apiKeyEnv`; `ResolvedProvider.apiKey` → `apiKeys: string[]` (unset/empty env vars skipped). - Adapters take an `ApiKeySource` (a fixed string OR a supplier); the registry builds a round-robin supplier over the resolved pool, so each outbound call picks the next key. Single-key and keyless providers behave exactly as before. - Docs/example: `apiKeyEnvs` on the Gemini example + `GEMINI_API_KEY_2` in `.env.example`; README note; SECURITY_REVIEW_LOG SR-008 (wider secret surface). Follow-up (not in this PR): on a 429, retry the *next key* before model fallback (needs executor/adapter awareness) — today rotation is per-request distribution. Tests - config resolves a pool from `apiKeyEnvs` (+ `apiKeyEnv`, skipping empties); the registry round-robins keys across successive requests (k1 → k2 → k1) and sends no auth header for a keyless pool. How to verify - `pnpm verify` → green (233 tests, coverage ≥90%) - `pnpm build` → green
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets a provider hold a pool of API keys and rotates across them per request, so
free-tier users can spread load over several keys instead of hammering one key's
limit. (Closes the round-robin gap from the v0.1.x audit.)
What changed
apiKeyEnvs(an array) alongsideapiKeyEnv;ResolvedProvider.apiKey→apiKeys: string[](unset/empty env vars skipped).ApiKeySource(a fixed string OR a supplier); the registrybuilds a round-robin supplier over the resolved pool, so each outbound call
picks the next key. Single-key and keyless providers behave exactly as before.
apiKeyEnvson the Gemini example +GEMINI_API_KEY_2in.env.example; README note; SECURITY_REVIEW_LOG SR-008 (wider secret surface).Follow-up (not in this PR): on a 429, retry the next key before model fallback
(needs executor/adapter awareness) — today rotation is per-request distribution.
Tests
apiKeyEnvs(+apiKeyEnv, skipping empties);the registry round-robins keys across successive requests (k1 → k2 → k1) and
sends no auth header for a keyless pool.
How to verify
pnpm verify→ green (233 tests, coverage ≥90%)pnpm build→ green