feat(google-vertex): support eu/us multi-region endpoints for Gemini models

[chanrute]

Description

Summary

The @ai-sdk/google-vertex Gemini provider (google-vertex-provider-base.ts) builds an incorrect hostname when location is set to 'us' or 'eu', producing a 404 Not Found for every request.

This is the same root-cause bug as #14634 (Anthropic provider on Vertex), which is already fixed in PR #14744. The fix has not been applied to the Gemini provider.

Problem

When location: 'us' or location: 'eu' is passed, the SDK builds the base URL as:

This host does not exist and the request returns 404 Not Found.

Vertex AI's multi-region endpoints (us, eu) use a Representative Endpoint (REP) hostname format, which is different from both the regional and global formats:

Location	Current (incorrect) URL	Correct URL
us-central1 (regional)	https://us-central1-aiplatform.googleapis.com/...	✅ correct
global	https://aiplatform.googleapis.com/...	✅ correct (fixed in #6810)
us (multi-region)	https://us-aiplatform.googleapis.com/...	❌ 404 — should be aiplatform.us.rep.googleapis.com
eu (multi-region)	https://eu-aiplatform.googleapis.com/...	❌ 404 — should be aiplatform.eu.rep.googleapis.com

Reference: Vertex AI Locations — Multi-region endpoints

---

Root cause

In packages/google-vertex/src/google-vertex-provider-base.ts:

// Current code (incorrect for us/eu multi-region)
const baseHost = `${region === 'global' ? '' : region + '-'}aiplatform.googleapis.com`;
const baseURL = `https://${baseHost}/v1beta1/projects/${project}/locations/${region}/publishers/google`;

For region = 'us', this produces us-aiplatform.googleapis.com, which is not a valid Vertex AI endpoint.

The same bug existed in google-vertex-anthropic-provider.ts and was fixed by PR #14744 using a getHost() helper. The same fix needs to be applied here.

---

Reproduction

Setup

mkdir vertex-repro && cd vertex-repro
npm init -y
npm install ai@6.0.193 @ai-sdk/google-vertex@4.0.140

export GOOGLE_VERTEX_PROJECT=your-project-id
export GOOGLE_VERTEX_LOCATION=us
# Authenticate via ADC: gcloud auth application-default login

repro.mjs

import { createVertex } from '@ai-sdk/google-vertex';
import { generateText } from 'ai';

const project = process.env.GOOGLE_VERTEX_PROJECT;

// ① Broken: no baseURL override → hits us-aiplatform.googleapis.com → 404
const vertexBroken = createVertex({
  project,
  location: 'us',
});

// ② Workaround: explicit REP baseURL
const vertexFixed = createVertex({
  project,
  location: 'us',
  baseURL: `https://aiplatform.us.rep.googleapis.com/v1/projects/${project}/locations/us/publishers/google`,
});

async function test(label, vertex) {
  console.log(`\n=== ${label} ===`);
  try {
    const { text } = await generateText({
      model: vertex('gemini-3.5-flash'),
      prompt: 'Say "hello" in one word.',
    });
    console.log('✅ Success:', text);
  } catch (e) {
    console.error('❌ Error:', e.message);
    if (e.url) console.error('   URL:', e.url);
  }
}

await test('① Broken (location: us, no baseURL)', vertexBroken);
await test('② Workaround (explicit REP baseURL)', vertexFixed);

Observed output

AI SDK Version

• ai: 6.0.193
• @ai-sdk/google-vertex: 4.0.140
• Also reproduced on main (HEAD ab6d664, 2026-05-29)

Code of Conduct

• I agree to follow this project's Code of Conduct

[shubhamgore2468]

Hi @chanrute , linking a PR for this fix PR

[aayush-kapoor]

looking into this!

[github-actions]

🚀 Published in:

Package	Version
@ai-sdk/google-vertex	5.0.0-canary.100 github npm

[lgrammel]

Identify issue type

Identified as Bug
Confidence: High

Rationale

This is a concrete failure in existing Google Vertex provider behavior: supported location values generate incorrect endpoints and make requests fail. Although the title uses feat, the report clearly describes and reproduces a bug.

Evidence

• Setting location to us or eu constructs invalid Gemini Vertex hostnames and causes every request to return 404 Not Found.
• Regional and global locations work, while multi-region locations require the documented REP hostname format.
• The issue includes a reproducible failure, a working baseURL workaround, and identifies the same root cause as a previously fixed provider bug.
• A linked fix was subsequently published in a canary release.