Add vertex explicitly as an available provider#844
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| "claude-fable-5": ["anthropic"], | ||
| "openai.gpt-oss-safeguard-120b": ["bedrock"], | ||
| "openai.gpt-oss-safeguard-20b": ["bedrock"], | ||
| "openai.gpt-5.5": ["bedrock"], |
There was a problem hiding this comment.
this was a drive-by from running sync-models, I need to seperately fix why this wouldn't have happened at model addition time.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bb66cfb31f
ℹ️ 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 (@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 (@codex) address that feedback".
| "available_providers": [ | ||
| "vertex" | ||
| ] |
There was a problem hiding this comment.
Keep provider-native Vertex lookups from inheriting Gemini
Adding available_providers: ["vertex"] here does not make this exact Vertex model ID Vertex-only for callers of getModelEndpointTypes: the reverse fallback scan in schema/index.ts still sees canonical gemini-2.5-flash listing this ID in fallback_models, then adds the canonical model's direct google endpoint as well. In the current catalog, publishers/google/models/gemini-2.5-flash therefore still resolves to both vertex and google, so the dual-credential 404 scenario described in the commit can still occur unless provider-native lookups stop inheriting canonical providers or direct provider restrictions are made authoritative.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
that is fine, we now prefer the vertex one
The failover work broadened the set of providers considered for each model by looking at equivalent/fallback models. For provider-native Vertex model names, that meant the gateway could receive both Gemini and Vertex credentials because the catalog entry itself did not explicitly say it was Vertex-only. Since those Vertex model names are not valid Gemini API model names, routing could select the Gemini provider and return a 404. This PR adds available_providers: ["vertex"] to provider-native Vertex catalog entries so gateway provider-default remapping resolves them to GOOGLE_DEFAULT_CREDENTIALS instead of falling back to Gemini.