feat(vertex): dynamic model discovery (surface image models + full catalog)

[artickc]

Problem

The vertex provider returned only its small hardcoded registry list from /v1/models (10 chat models, e.g. gemini-3-flash-preview, gemini-3.1-flash-lite, plus a few partner models) — and no image-generation models at all. Vertex AI accounts expose far more (Imagen, gemini-*-image, embeddings, etc.), but those were never discoverable because vertex was not wired into the model-discovery pipeline (PROVIDER_MODELS_CONFIG / per-provider discovery branches). It fell through to the static local_catalog.

Fix

Add a dedicated vertex / vertex-partner branch to the model-discovery route (GET /api/providers/[id]/models) that lists models from the Google Generative Language endpoint:

GET https://generativelanguage.googleapis.com/v1beta/models?pageSize=1000

Both Vertex auth modes are supported (reusing the executor's existing credential helpers):

• Express-mode API key → passed as the ?key= query param (verified: returns the full live catalog, 55 models incl. gemini-3-pro-image, gemini-2.5-flash-image, imagen-4.0-*).
• Service Account JSON → a short-lived OAuth token is minted (parseSAFromApiKey → getAccessToken) and sent as Authorization: Bearer.

Each model's supportedGenerationMethods is mapped to OmniRoute endpoints via a shared, unit-tested parseGeminiModelsList helper (extracted from the existing gemini config so both share one implementation):

method	endpoint
generateContent / generateAnswer	chat
predict / predictLongRunning	images (Imagen)
embedContent	embeddings
bidiGenerateContent	audio

Discovered models flow through the standard buildApiDiscoveryResponse → persistDiscoveredModels path (pagination via nextPageToken), so the unified catalog auto-swaps the static list for the live one. On any error or missing/unusable credential it falls back to the cached then static catalog (no regression for existing Vertex connections).

Tests

tests/unit/gemini-models-parser.test.ts (5 tests, all pass) covers the method→endpoint mapping, the models/ prefix stripping + display-name handling, image models (gemini-*-image → chat, imagen-* → images), embeddings/audio, and empty/missing-input tolerance.

node --import tsx --test tests/unit/gemini-models-parser.test.ts
# pass 5, fail 0

Notes

• Discovery is activated by the existing sync mechanisms (manual sync or providerSpecificData.autoSync); this PR only makes Vertex capable of dynamic discovery.
• The shared helper keeps the gemini provider behavior unchanged (it now calls parseGeminiModelsList).

[gemini-code-assist]

Code Review

This pull request extracts Gemini model parsing into a reusable utility (parseGeminiModelsList) and introduces dynamic model discovery for Vertex AI and Vertex Partner providers. It also adds unit tests for the new parser. A critical issue was identified in the Vertex AI discovery logic, where non-existent helper functions (isExpressApiKey and looksLikeServiceAccountJson) are imported, which would cause a runtime crash. It is recommended to determine the credential type by attempting to parse it as JSON instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The helper functions isExpressApiKey and looksLikeServiceAccountJson are imported from @omniroute/open-sse/executors/vertex.ts, but they are not exported or defined in that file. This will cause a runtime TypeError and crash the model discovery process for Vertex AI.

Instead of importing these non-existent helpers, we can determine the credential type directly by checking if the credential is valid JSON (which indicates a Service Account JSON) or a plain string (which indicates an Express API key).

        const { parseSAFromApiKey, getAccessToken } =
          await import("@omniroute/open-sse/executors/vertex.ts");
        if (accessToken) {
          bearerToken = accessToken;
        } else if (credential) {
          let isSaJson = false;
          try {
            JSON.parse(credential);
            isSaJson = true;
          } catch {}

          if (isSaJson) {
            bearerToken = await getAccessToken(parseSAFromApiKey(credential));
          } else {
            queryKey = credential;
          }
        }

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	2
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
src/app/api/providers/[id]/models/route.ts	2045	vertex-partner is included in the Generative Language discovery branch, so a successful live discovery response can replace the partner-only static catalog instead of preserving/augmenting those models.

Other Observations (not in diff)

Issues found in unchanged code that cannot receive inline comments:

File	Line	Issue
src/lib/providers/validation.ts	3955, 3967	The existing Vertex validation path still requires Service Account JSON for both vertex and vertex-partner, which conflicts with the PR's new Express-mode API key discovery support.

Files Reviewed (3 files)

• src/app/api/providers/[id]/models/route.ts — 1 new issue; previous allModels typing issue is resolved at line 2109 and the non-exported helper import is no longer present.
• src/lib/providerModels/geminiModelsParser.ts
• tests/unit/gemini-models-parser.test.ts

Fix these issues in Kilo Cloud

---

_{Reviewed by nex-n2-pro:free · 1,980,315 tokens}

[kilo-code-bot]

WARNING: allModels is typed as any[] instead of GeminiDiscoveryModel[]

parseGeminiModelsList returns GeminiDiscoveryModel[], but the array collecting its results is typed as any[]. This loses type safety for all downstream operations on allModels (e.g., buildApiDiscoveryResponse at line 2142) and prevents the compiler from catching property mismatches if the parser's return type ever changes.

const allModels: GeminiDiscoveryModel[] = [];

---

_{Reply with @kilocode-bot fix it to have Kilo Code address this issue.}

[kilo-code-bot]

To use Kilo from GitHub you first need to link your GitHub account to Kilo. Link your Kilo account to continue. After linking, mention me again in this issue or pull request.

[kilo-code-bot]

WARNING: vertex-partner dynamic discovery can replace the partner-only catalog

This branch treats vertex-partner the same as vertex and returns buildApiDiscoveryResponse(allModels) when the Generative Language endpoint returns any models. The live endpoint lists Google Gemini/Imagen models, not the partner models in the static vertex-partner registry (open-sse/config/providerRegistry.ts:3458, e.g. DeepSeek-V4-*, Qwen3.6-*, GLM-5.1-FP8, and Claude partner models). A successful discovery response can therefore drop those partner-only models instead of augmenting the local catalog.

Merge discovered models with the local catalog for vertex-partner, or exclude vertex-partner from this branch if it is not served by the Generative Language API.

_{Reply with @kilocode-bot fix it to have Kilo Code address this issue.}

[kilo-code-bot]

To use Kilo from GitHub you first need to link your GitHub account to Kilo. Link your Kilo account to continue. After linking, mention me again in this issue or pull request.

[diegosouzapw]

Thanks @artickc — merged into release/v3.8.23 🎉

This is a great follow-up to your Vertex Express-mode work (#3690): Vertex now flows through the standard model-discovery pipeline, so Imagen / gemini-*-image / embedding / audio models surface dynamically instead of being capped to the static registry list. The shared parseGeminiModelsList helper keeps the gemini provider behavior identical, and the cached→static fallback means zero regression for existing Vertex connections.

Validated locally: gemini-models-parser.test.ts 5/5, typecheck:core clean. Will ship in the upcoming v3.8.23 release.