feat(openrouter): support multiple named keys in usage command#16
feat(openrouter): support multiple named keys in usage command#16IgorWarzocha wants to merge 2 commits intomasterfrom
Conversation
Summary of ChangesHello @IgorWarzocha, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly improves the management and reporting of OpenRouter API usage by introducing support for multiple named API keys. Users can now define distinct OpenRouter keys in their configuration, query usage for specific keys via the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds support for multiple named OpenRouter API keys, which is a great enhancement. The implementation is solid, with updates to configuration, command parsing, and usage fetching logic. I've found one potential issue with handling duplicate key names in the configuration, which could lead to silently ignoring some keys. My review includes a suggestion to fix this to make the feature more robust.
src/usage/registry.ts
Outdated
| const entries: ProviderAuthEntry[] = [] | ||
| const seenKeys = new Set<string>() | ||
|
|
||
| const configuredKeys = Array.isArray(config?.openrouterKeys) ? config.openrouterKeys : [] | ||
| for (const configured of configuredKeys) { | ||
| const key = configured?.key?.trim() | ||
| if (!key || seenKeys.has(key)) continue | ||
| const rawName = configured?.name?.trim() | ||
| const name = rawName || `key-${entries.length + 1}` | ||
| if (configured.enabled === false) continue | ||
| seenKeys.add(key) | ||
| entries.push({ | ||
| providerID: "openrouter", | ||
| entryID: `openrouter:${name}`, | ||
| auth: { key, keyName: name }, | ||
| }) | ||
| } |
There was a problem hiding this comment.
The current implementation does not handle cases where multiple OpenRouter keys are configured with the same name in usage-config.jsonc. This can lead to one of the keys being silently overwritten in the usage report because they will have the same entryID. To prevent this, you should track seen key names (case-insensitively) and skip any duplicates.
const entries: ProviderAuthEntry[] = []
const seenKeys = new Set<string>()
const seenNames = new Set<string>()
const configuredKeys = Array.isArray(config?.openrouterKeys) ? config.openrouterKeys : []
for (const configured of configuredKeys) {
const key = configured?.key?.trim()
if (!key || seenKeys.has(key)) continue
const rawName = configured?.name?.trim()
const name = rawName || `key-${entries.length + 1}`
if (configured.enabled === false) continue
if (seenNames.has(name.toLowerCase())) continue
seenKeys.add(key)
seenNames.add(name.toLowerCase())
entries.push({
providerID: "openrouter",
entryID: `openrouter:${name}`,
auth: { key, keyName: name },
})
}![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7049a98cd9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .map(async e => { | ||
| const snap = await providers[e.providerID]?.fetchUsage?.(e.auth).catch(() => null) | ||
| if (snap) { | ||
| snapshotsMap.set(e.providerID, snap) | ||
| snapshotsMap.set(e.entryID, snap) | ||
| fetched.add(e.providerID) | ||
| } |
There was a problem hiding this comment.
When multiple OpenRouter keys are configured, the fetch loop records success in fetched by provider ID only. If one key succeeds and another key fails (bad key, rate limit, etc.), appendMissingStates will think OpenRouter is fully fetched and won’t emit any missing snapshot for the failed key, so that key silently disappears from /usage output. This regression shows up only when multiple keys are configured and at least one fails; consider tracking fetched by entryID (or emitting per-key missing snapshots) so users see failures for individual keys.
Useful? React with 👍 / 👎.
1 participant
Summary
usage-config.jsoncviaopenrouterKeys/usagecommand parsing to support/usage openrouter <key_name>and filter to a single named keyValidation