feat: add Google Vertex AI provider (AnthropicVertex SDK)

[EgorLu]

What does this PR do?

Adds native support for running Claude models on Google Vertex AI using Anthropic's AnthropicVertex SDK adapter. Users set provider: vertex in config and authenticate via Google Application Default Credentials (ADC) — no Anthropic API key needed. Useful for corporate GCP environments where direct Anthropic API access is unavailable.

Architecture: follows the Bedrock pattern

The provider is named vertex (not vertex-anthropic) because Vertex AI is a cloud platform that hosts models from multiple vendors analogous to how Bedrock is named bedrock, not bedrock-anthropic.
The implementation mirrors Bedrock's dual-path routing:

• Runtime resolution checks the model name via _is_anthropic_vertex_model() (mirrors is_anthropic_bedrock_model())
• Claude models → api_mode: anthropic_messages + AnthropicVertex SDK for full feature parity (prompt caching, thinking budgets)
• Non-Claude models → clear error noting Gemini/other support is planned (the routing infrastructure is ready for future expansion)

Configuration

export ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project
export CLOUD_ML_REGION=global  # optional
gcloud auth application-default login

# ~/.hermes/config.yaml
model:
  default: claude-sonnet-4-6
  provider: vertex

vertex:
  project_id: your-gcp-project
  region: global

Related Issue

Closes #13484
Closes #12639
Related: #3569, #6491 (prior attempts with smaller scope — this PR covers full CLI integration, model-based routing, docs, and tests)

Type of Change

• ✨ New feature (non-breaking change that adds functionality)

Changes Made

Provider registration

• plugins/model-providers/vertex/ — ProviderProfile with gcp_adc auth type, aliases (google-vertex, gcp-vertex, vertex-ai, vertex-anthropic)
• hermes_cli/auth.py — ProviderConfig, get_vertex_auth_status(), resolve_vertex_anthropic_runtime_credentials()
• hermes_cli/runtime_provider.py — model-based routing with _is_anthropic_vertex_model()

CLI integration

• hermes_cli/models.py — ProviderEntry, aliases, static model catalog
• hermes_cli/main.py + model_setup_flows.py — _model_flow_vertex() setup wizard (project ID, region, model selection)

Runtime wiring

• agent/anthropic_adapter.py — build_anthropic_vertex_client() (lazy-installs anthropic[vertex], excludes context-1m beta)
• agent/agent_init.py — Vertex client construction branch (parallel to Bedrock)
• run_agent.py — _rebuild_anthropic_client Vertex dispatch
• agent/agent_runtime_helpers.py — runtime recovery, restore, switch_model Vertex paths
• agent/chat_completion_helpers.py — fallback activation Vertex path
• agent/auxiliary_client.py — vision backend + auxiliary resolution for gcp_adc auth type

Dependencies

• pyproject.toml — anthropic-vertex optional extra (anthropic[vertex]==0.87.0)
• tools/lazy_deps.py — lazy install entry

Tests (7 new, 702 total passing)

• tests/agent/test_anthropic_adapter.py — 2 tests (client construction, SDK requirement)
• tests/hermes_cli/test_runtime_provider_resolution.py — 3 tests (env var precedence, fallback, missing project)
• tests/run_agent/test_run_agent.py — 2 tests (init dispatch, rebuild dispatch)

Docs

• website/docs/guides/vertex-ai.md — full guide (prerequisites, quick start, config, troubleshooting)
• website/docs/integrations/providers.md — providers table entry

How to Test

1. Set up GCP credentials:

   export ANTHROPIC_VERTEX_PROJECT_ID=your-project
   gcloud auth application-default login

2. Run the setup wizard:

   hermes model  # choose "Google Vertex AI"

3. Chat:

   hermes chat -q "Hello from Vertex"

4. Run tests:

   python -m pytest tests/hermes_cli/test_runtime_provider_resolution.py::TestVertexRuntimeResolution tests/agent/test_anthropic_adapter.py tests/run_agent/test_run_agent.py::TestVertexClientSelection -v

Checklist

• I've tested these changes locally
• Tests pass
• New tests added for new functionality
• Documentation updated
• No breaking changes to existing functionality

[EgorLu]

Verified e2e functionality.
Later we can add additional models support by demand.

[rodriguez46p-ui]

Hermes Agent Review — PR #55742

Verdict: changes requested (configuration persistence bug)

Blocking finding

• hermes_cli/model_setup_flows.py:2315-2323 saves the Vertex project and region under vertex.project_id / vertex.region in config.yaml, and website/docs/guides/vertex-ai.md:42-52 documents that as the post-setup configuration. However, hermes_cli/auth.py:6285-6291 only resolves project/region from environment variables (ANTHROPIC_VERTEX_PROJECT_ID, GOOGLE_CLOUD_PROJECT, GCLOUD_PROJECT, CLOUD_ML_REGION) and never reads the saved vertex config section. As a result, a user who completes hermes model successfully can still fail at runtime unless they also export the env vars manually.

Reproduction evidence

In a detached PR worktree, I wrote a temp HERMES_HOME/config.yaml containing:

model:
  provider: vertex
  default: claude-sonnet-4-6
vertex:
  project_id: config-project
  region: europe-west4

with all Vertex env vars cleared, then called resolve_runtime_provider(requested='vertex'). It failed with:

AuthError No Vertex Anthropic project configured. Set ANTHROPIC_VERTEX_PROJECT_ID, GOOGLE_CLOUD_PROJECT, or GCLOUD_PROJECT. missing_vertex_project

Suggested fix

Teach resolve_vertex_anthropic_runtime_credentials() to read config.yaml's vertex.project_id and vertex.region after the env-var precedence (or make the setup flow persist to the same source the resolver uses). Add a regression test that creates a temp Hermes home with only vertex.project_id / vertex.region configured and asserts resolve_runtime_provider(requested='vertex') succeeds.

Checks run

• git diff --check origin/main...HEAD — passed.
• Focused PR tests passed:
  • tests/hermes_cli/test_runtime_provider_resolution.py::TestVertexRuntimeResolution
  • tests/agent/test_anthropic_adapter.py::TestBuildAnthropicClient::test_vertex_client_uses_project_and_region
  • tests/run_agent/test_run_agent.py::TestVertexClientSelection
• Additional ad-hoc config-only probe exposed the blocker above.

Reviewed by Hermes Agent hourly commander.

[alt-glitch]

This was generated by AI during triage.

Competing-implementation cluster for native Google Vertex AI support (Claude via the AnthropicVertex SDK), all currently OPEN: #3569 (earliest, canonical), #6491, #27356, and this PR. The Gemini-on-Vertex sibling is #36253. Feature issues: #13484, #12639. Per triage duplicate-discipline these are related, not duplicates of one another — a maintainer should pick one of the AnthropicVertex-Claude implementations to carry forward.

[EgorLu]

Thanks for the triage. A few notes on why this PR may be the one to carry forward:

Scope comparison:

• feat(providers): add Google Vertex AI provider for Claude #3569 (126 lines): core wiring only, no tests, no CLI, no docs
• feat: add Google Vertex AI as a first-class Claude provider #6491 (567 lines): broader, 16 tests, partial CLI, but reviewer noted it as duplicate of feat(providers): add Google Vertex AI provider for Claude #3569
• feat(vertex): add Google Cloud Vertex provider #27356 (108 lines): core wiring only, no tests, sweeper found integration blockers (alias resolution, project/region propagation)
• This PR (987 lines): full implementation -- provider plugin, CLI setup wizard (hermes model), models.py catalog/aliases, Bedrock-style model-based routing, config.yaml fallback, 10 tests, docs guide, providers table entry

Architecture: Named vertex (not vertex-anthropic) following the Bedrock pattern -- cloud platform name with model-based routing. Claude models use AnthropicVertex SDK; the routing infrastructure is ready for future Gemini/OpenAI-compat expansion.

Already verified: live smoke-tested against real Vertex credentials (plain text + tool calls), and the config persistence bug flagged in review is fixed.

Happy to cherry-pick any useful ideas from the other PRs if there's something I missed.

[EgorLu]

@teknium1 rebased upon your PR

[balajisiva]

Local validation (enterprise GCP / ADC)

Tested branch feat/vertex-provider on macOS with Application Default Credentials against a private corporate GCP project with Vertex Claude access.

hermes auth status vertex → logged in
Plain chat with claude-sonnet-4-6, region global → success
Config-only path (vertex.project_id / vertex.region in config.yaml, Vertex env vars unset) → success (config persistence fix looks good)
Tool calling via terminal tool → success
Focused pytest suite for Vertex resolution/client selection → 24/24 passed
This unblocks our Hermes adoption for always-on agents on Vertex. Happy to help review or test follow-up commits. Details of our environment available privately if useful.

[EgorLu]

@teknium1 can we proceed with this addition?

[teknium1]

Thanks for carrying the AnthropicVertex implementation through runtime, switching, recovery, tests, and documentation. Current main already ships Vertex Gemini support in c73e74386, so this needs to extend that dual-provider surface rather than replace its assumptions.

Problems

• agent/agent_init.py:455 unconditionally maps provider="vertex" to anthropic_messages when no API mode is supplied. That bypasses the PR's model-based routing for direct Gemini AIAgent construction.
• agent/auxiliary_client.py:5137 checks auth_type == "gcp_adc", but plugins/model-providers/vertex/__init__.py:71 still defines Vertex as auth_type="vertex"; the new AnthropicVertex auxiliary branch is unreachable.
• hermes_cli/model_setup_flows.py:2428-2445 remains Gemini-only, while website/docs/guides/vertex-ai.md:11-12 incorrectly says Gemini is unsupported. The new page is not registered in website/sidebars.ts, which still links guides/google-vertex at line 704.

Suggested changes

• Preserve the existing Gemini OAuth/OpenAI path and make Claude-vs-Gemini routing model-aware across initialization and auxiliary clients.
• Add focused tests for direct initialization, auxiliary resolution, and both wizard-selected model families.
• Consolidate the docs with website/docs/guides/google-vertex.md and keep provider documentation truthful for both paths.

This is an automated hermes-sweeper review.

[teknium1]

This forces every direct AIAgent(provider="vertex") construction into Anthropic mode before the model can be considered. Preserve the current Gemini chat_completions path and select AnthropicVertex only when the resolved model is Claude.

[teknium1]

This branch is unreachable for Vertex: the provider profile still declares auth_type="vertex", so resolve_provider_client("vertex", claude_model) takes the existing Gemini branch. Route Claude model selection within the existing Vertex branch and add an auxiliary-client regression test.

[teknium1]

This conflicts with current main's shipped Gemini-on-Vertex path (hermes_cli/runtime_provider.py:1579-1610) and with this PR's Gemini else path. Consolidate this with the existing guides/google-vertex.md instead of documenting Vertex as Claude-only.

[EgorLu]

@teknium1 Any progress with getting this merged?
Without an official support, each user / employee of the company using Vertex is required to manually patch their installation on every update.