Fix for Incomplete OpenRouter Model Listing#179
Closed
OverbearingPearl wants to merge 1 commit intocecli-dev:mainfrom
Closed
Fix for Incomplete OpenRouter Model Listing#179OverbearingPearl wants to merge 1 commit intocecli-dev:mainfrom
OverbearingPearl wants to merge 1 commit intocecli-dev:mainfrom
Conversation
- Add support for listing available models from OpenRouter - Implement `get_openrouter_models` to fetch models from the OpenRouter API
Collaborator
|
As far as I can tell, this wouldn't work to allow a user to actually use a model that's listed in OpenRouter, that's outside of LiteLLM's corpus of models. The data structure in that openrouter api route does not correspond to model_prices_and_context_window.json which declares what a model costs and what it supports. I don't think we need to add the full corpus of OpenRouter in memory. This PR would be useful if it can match an unknown model name to the OpenRouter model and then use the relevant information from the API to build the underlying Model objects used by LiteLLM. It would work as essentially a fallback, and at that point it might start to obviate/augment the need to copy model_prices_and_context_window.json into model-settings.json as well as keeping pricing and such up to date. |
Author
|
Hello @dwash96 Thanks for your review. Before this change, it works like this: After this change, it looks like this: How do you think about it? |
Author
|
By the way, I couldn't get the motivation about model_prices_and_context_window.json |
Collaborator
Yes, the information on the default models allowed by the system ate maintained in: Because aider is heavily built over LiteLLM, the above model-metadata.json file is actually a ripped version of: These are the only identifiers the system will recognize as valid model names. It is technically possible to specify custom models per: What I would recommend for this kind of PR is to essentially be able to do this automatically for openrouter models based on what is returned in the openrouter API and the format present in the model-metadata.json file. Basically, instead of storing every possible model in an incompatible format like this PR does currently, use the openrouter API to actually configure models that are not present in the metadata |
Author
Oh great! Thank you so much. I'll try to make that. |
Author
|
The model I needed (Gemini-3) has been added by other as @dwash96 mentioned. |
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
2 participants
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.
Previously, Aider could not display all available models from OpenRouter, causing newer models like
openrouter/google/gemini-3-pro-previewto be missing from the/modelscommand output. This issue stemmed from Aider's reliance on static and cached model lists provided by the LiteLLM library, which were often outdated or incomplete.The fix resolves this by implementing a direct, real-time API call to OpenRouter to fetch its complete and up-to-date model catalog, ensuring all available models are discoverable within Aider.
The Problem: Reliance on Stale and Incomplete Data
Before this change, Aider's mechanism for discovering models had a critical flaw: it had no direct communication channel with OpenRouter to learn about its available models. Instead, it relied on two indirect sources:
LiteLLM's Built-in Model List (
litellm.model_cost):litellmpackage itself is updated. If OpenRouter added a new model, Aider would remain unaware of it until a new version of LiteLLM was released and integrated.Cached LiteLLM Model Database:
model_prices_and_context_window.json) from LiteLLM's GitHub repository.In essence, Aider was relying on second-hand information that was frequently out of sync with the ground truth at OpenRouter.
The Solution: Direct API Integration
The code modification addresses this root cause by shifting from a passive, cache-based approach to an active, real-time query. This is achieved through three key changes:
Fetching Real-time Data (
get_openrouter_models):GETrequest to OpenRouter's official API endpoint:https://openrouter.ai/api/v1/models.Dynamic Search Pool Injection (
fuzzy_match_models):fuzzy_match_modelsfunction, which powers the model search, was modified to call the newget_openrouter_modelsfunction.openrouter/) into the pool of searchable models. This ensures that as soon as OpenRouter adds a new model, Aider can find and use it without requiring a code update.