Google Vertex AI

Vertex serves Gemini and Claude from your own GCP project, so tokens bill to your Google Cloud account and traffic stays inside your project’s IAM and VPC-SC boundary. There is no API key: yottacode authenticates with Application Default Credentials and mints a fresh access token for every request.

Configure

In the TUI — setup and /provider add show one Google Vertex AI row with a Gemini/Claude family dropdown plus a GCP project field:

/provider                   # open the picker → Add a profile: Google Vertex AI
/provider use vertex-claude # switch to a saved profile

First, sign in with ADC:

gcloud auth application-default login

Vertex serves the two model families over different surfaces, so yottacode keeps two provider kinds internally. The full Vertex base_url is derived from the project and family you pick, so you do not have to edit the long endpoint by hand:

Kind	Models	Surface
`vertex`	Gemini	the project’s OpenAI-compatible chat shim
`vertex-anthropic`	Claude	`:streamRawPredict` (native Messages API)

Both carry the GCP project and location inside base_url rather than in separate fields:

[[providers]]
name          = "vertex-claude"
kind          = "vertex-anthropic"
base_url      = "https://aiplatform.googleapis.com/v1/projects/YOUR-PROJECT/locations/global"
default_model = "claude-sonnet-4-5@20250929"

[[providers]]
name          = "vertex-gemini"
kind          = "vertex"
base_url      = "https://us-central1-aiplatform.googleapis.com/v1/projects/YOUR-PROJECT/locations/us-central1/endpoints/openapi"
default_model = "google/gemini-2.5-pro"

No api_key_env — ADC supplies the credential. GOOGLE_APPLICATION_CREDENTIALS may point at a service-account key instead of a user login.

Model names and locations

Three things catch people out:

Claude ids need Vertex’s version suffix — claude-sonnet-4-5@20250929, not claude-sonnet-4-5. A bare id is not servable. Ids ending @default track the latest snapshot.
Gemini ids are publisher-namespaced on the shim — google/gemini-2.5-pro.
Location matters — Claude is safest on locations/global; Gemini’s OpenAI-compatible shim is regional in practice. The Gemini URL must keep the hostname and path location in sync, for example https://us-central1-aiplatform.googleapis.com/v1/projects/P/locations/us-central1/endpoints/openapi.

Both kinds are curated: the /model picker reads yottacode’s local models.dev snapshot, filtered to the family each kind can actually drive. Vertex has no list-models endpoint worth reading — the chat shim doesn’t implement one, and the publisher-model endpoint returns the whole Model Garden (image classifiers, deploy-it-yourself entries, and models your region won’t serve). Add anything the picker lacks under [[providers.models]].

Check model access

Vertex access is project-specific, so a model can appear in the public catalog but still 404 for your project/location until access is granted in Vertex Model Garden. Run an access scan after configuring a Vertex provider:

yottacode provider scan vertex-claude
# or, for the Gemini family
yottacode provider scan vertex-gemini

The scan sends tiny test requests with ADC, writes the result under ~/.yottacode/auth/vertex-models/<project>/<location>/, and the /model picker greys out scanned models your project cannot call with no access. Re-run the scan after enabling new Vertex models or changing the provider’s location.

Reasoning effort

Both families reason, both report thinking tokens to /usage, and /effort steers both. Claude uses the same extended-thinking budget as the direct Anthropic provider. Gemini goes through the shim’s reasoning_effort enum — note this is the shim’s own knob, not Gemini’s native thinkingBudget, which the shim does not expose.

Gemini xAI