feat(vertex): add native Gemini support to GeminiNativeClient (mirrors Anthropic Vertex pattern)

[TAMdrew]

What does this PR do?

Adds Vertex AI support to the existing GeminiNativeClient so users with custom_providers configured against the publisher endpoint stop hitting silent 404s on every auxiliary call.

This is the symmetric companion to agent/anthropic_adapter.py, which already handles Claude-on-Vertex (:rawPredict / :streamRawPredict with GCE bearer auth). Same approach, applied to Gemini.

The bug this fixes

When you configure a custom_provider pointing at the native Vertex publisher endpoint:

custom_providers:
  - name: vertex-gemini-3-flash
    base_url: https://aiplatform.googleapis.com/v1/projects/<P>/locations/global/publishers/google/models/gemini-3-flash-preview:generateContent
    auth: gce_metadata          # GCE bearer token from metadata server

…the OpenAI SDK takes over (because the URL doesn't match any existing adapter predicate), appends /chat/completions to a URL that already ends in :generateContent, and the request silently 404s. The main agent path happens to use a different code branch and still works, but every auxiliary call breaks:

• /compress → "Compression summary failed: Error code: 404"
• Session title generation → no titles, just timestamps
• vision_analyze on Gemini → "Generation failed"
• Curator runs → empty results
• web_extract / browser_automation → silent failures

The user-visible symptom is "everything mostly works but the side features are broken", which is hard to root-cause without reading the auxiliary client routing code.

Fix

Three small changes that mirror the existing Anthropic Vertex pattern:

agent/gemini_native_adapter.py (+138)

• is_native_gemini_base_url() now recognises aiplatform.googleapis.com/.../publishers/google URLs (it previously only matched generativelanguage.googleapis.com)
• New is_vertex_gemini_base_url() helper for code that needs to branch on Vertex specifically
• _strip_vertex_model_suffix() removes /models/<NAME>:generateContent (or :streamGenerateContent) at adapter init — the OpenAI SDK treats base_url as a prefix and would otherwise produce malformed paths
• _fetch_gce_metadata_token() — minimal GCE metadata-server client, copy of the pattern in anthropic_adapter
• GeminiNativeClient.__init__ records ._is_vertex and strips the suffix; ._headers() injects Authorization: Bearer <token> on Vertex and drops any inherited x-goog-api-key (which would otherwise trigger GCP's 400 Multiple authentication credentials received)

agent/auxiliary_client.py (+27 −0)

• resolve_provider_client._wrap_if_needed() gains a Gemini-native gate that runs first — before the Codex/Anthropic/etc rewrap checks — because Vertex Gemini URLs match no other adapter's predicate but always need GeminiNativeClient

run_agent.py (+95 −14)

• Main agent's client construction routes Vertex Gemini base URLs through GeminiNativeClient (mirrors the auxiliary path so all routes are consistent)

Tests

tests/agent/test_gemini_vertex_native.py (new, 11 tests, all passing):

• URL recognition — vertex publisher URLs match, GenLang still matches, unrelated URLs (api.openai.com, vertex Anthropic) don't
• Suffix stripping — idempotent on already-clean base, handles :generateContent and :streamGenerateContent
• Auth headers — Vertex injects bearer + drops x-goog-api-key; GenLang keeps x-goog-api-key + no bearer
• End-to-end — resolve_provider_client(provider='custom', explicit_base_url=<vertex>) returns a GeminiNativeClient (the regression that would cause silent 404s without the gate)

The 2 pre-existing failures in tests/run_agent/test_concurrent_interrupt.py (AttributeError: '_Stub' object has no attribute '_tool_guardrails') reproduce identically on pristine main without this patch — they're unrelated to this change.

Manual validation

I've been running this patch on my live Hermes runtime since 2026-05-05 against a real GCP project. Auxiliary title generation correctly routes to the Vertex URL with no 404 follow-up:

agent.auxiliary_client: Auxiliary title_generation: using custom (gemini-3.1-flash-lite-preview)
  at https://aiplatform.googleapis.com/v1/projects/<P>/locations/global/publishers/google

/compress, vision_analyze, curator, and web_extract all work without 404s on Gemini-on-Vertex endpoints.

Type of Change

• Bug fix (non-breaking change that fixes broken behaviour for custom_providers pointed at the native Vertex publisher endpoint)
• New feature (Vertex AI Gemini support — but via the existing custom_providers path, no new top-level provider added)

Related Issues / PRs

• Closes part of Feature: native Google Cloud Vertex AI provider support #13484 (native Vertex AI provider support — this fixes the Gemini half via custom_providers)
• Closes part of [Feature]: Support for Native Google / Vertex AI Provider (Bypass OpenRouter 402 Errors & Rate Limits) #12639 (bypass OpenRouter for Gemini-on-Vertex via direct GCP)
• Complementary to feat(vertex): add Vertex AI provider for Gemini models (service account + ADC) #8427 and feat(providers): add Google Vertex AI as a first-class inference provider #16010 — those PRs add a first-class vertex provider that uses Vertex's OpenAI-compatible endpoint (/endpoints/openapi/chat/completions). This PR keeps the existing custom_providers path working when pointed at the native :generateContent endpoint, which has better multimodal support and native function-calling than the OpenAI compat shim. The two paths can coexist.
• Pattern reference: existing Anthropic Vertex :rawPredict interceptor in agent/anthropic_adapter.py (already merged) — same shape, different model family

Backwards compatibility

• is_native_gemini_base_url() retains its existing behaviour for generativelanguage.googleapis.com URLs (test asserts this)
• GeminiNativeClient.__init__ for non-Vertex URLs is unchanged (_is_vertex=False branch is a no-op)
• _wrap_if_needed() — the new Vertex Gemini gate runs first but only fires when is_native_gemini_base_url() matches, so non-Gemini URLs flow through the original adapter chain unchanged
• No new configuration keys required — uses the existing custom_providers mechanism
• No new dependencies (GCE metadata client uses stdlib urllib)

Checklist

• Code follows the project's style (matched existing agent/anthropic_adapter.py patterns for Vertex GCE auth)
• Added regression tests (tests/agent/test_gemini_vertex_native.py, 11 tests)
• All new tests pass; no regressions in adjacent test files
• Validated manually against a real GCP project for ~3 days before opening this PR
• No new dependencies added
• No breaking changes to existing config or behaviour

[joofsh]

@TAMdrew anything left to do on this PR that we can help with? My company is eager to get hermes working with gemini+vertex

[teknium1]

Superseded by #56363, which adds Google Vertex AI as a first-class Gemini provider on current main (OAuth2 via service-account JSON / ADC on the OpenAI-compatible endpoint, per-turn token refresh, setup/model/desktop pickers, docs + tests).

That PR salvaged the earliest submission in this cluster (#8427 by @slawt) and preserved its authorship. Closing this as a duplicate — thanks for working on the same gap; the merged implementation covers the Gemini-via-Vertex use case. If you spot something it misses, please open a focused follow-up.