Google Vertex AI
Gemini models under Google Cloud governance — project-scoped credentials via gcloud access tokens, the same generateContent wire dialect, deliberately last in auto-detection.
Vertex AI serves the same Gemini models over the same wire dialect as the Gemini API — the difference is governance. Inference runs inside your Google Cloud project, billed to your account, subject to your IAM, quotas, and data-residency controls. If your organization requires Google Cloud to be the front door, this is the provider; if not, the plain Gemini API is one env var instead of three.
Setup
Vertex authenticates with a Google Cloud access token and needs a project:
export VERTEX_ACCESS_TOKEN=$(gcloud auth print-access-token)
export VERTEX_PROJECT_ID="my-gcp-project" # or GOOGLE_CLOUD_PROJECT
export VERTEX_LOCATION="global" # optional — this is the defaultGOOGLE_CLOUD_PROJECT works in place of VERTEX_PROJECT_ID; VERTEX_LOCATION defaults
to global and only needs setting if you pin a regional endpoint.
gcloud access tokens expire (typically after an hour). For long sessions, re-export
before a run or wrap the export in a shell function — an expired token surfaces as a
401 from the API mid-run.
The shell function, concretely — mint a fresh token per invocation and forget about expiry:
# ~/.zshrc or ~/.bashrc
stella-vertex() {
VERTEX_ACCESS_TOKEN="$(gcloud auth print-access-token)" stella "$@"
}stella-vertex --model vertex/gemini-3-pro run "audit the IAM bindings module"Each call gets a token good for about an hour — enough for the run it starts, and the next call mints its own.
Selecting models
The provider id is vertex; the default model is gemini-3-pro, and the lineup mirrors
the Gemini API.
stella --model vertex/gemini-3-pro run "audit the IAM bindings module"Pinning with --model vertex/… matters here, because of detection order.
Last in auto-detection — on purpose
Vertex sits last in auto-detection (alongside
Bedrock), deliberately: VERTEX_ACCESS_TOKEN and ambient Google Cloud credentials are
routinely present in shells for reasons that have nothing to do with LLM inference, and a
generic cloud credential must never hijack provider selection. If you want Vertex, say so —
--model vertex/gemini-3-pro, or set it as a default in
settings.json:
{
"agent_engine_config": {
"default_model": "vertex/gemini-3-pro"
}
}The pin sits between the --model flag and auto-detection — an explicit flag still
wins, but Vertex no longer loses to whichever direct-vendor key is also in the shell.
Thinking
Identical to the Gemini API: Stella's effort setting maps to thinkingLevel
(low/high), and Gemini 3 cannot fully disable thinking — reasoning: "off" yields
the minimum level, not zero.
In the pipeline
Same models, same roles as Gemini — a 1M-window worker or
judge — chosen when inference must stay inside your cloud perimeter. Route it per agent
with agent_engine_config; see
Examples for profile patterns.
Catalog pricing
| Model | Context | In $/Mtok | Out $/Mtok | Cached-in $/Mtok |
|---|---|---|---|---|
gemini-3-pro | 1M | 1.25 | 10.00 | 0.31 |
Catalog list prices from Stella's seed catalog mirror the Gemini API rates — your actual
Vertex billing is set by your Google Cloud agreement; verify there. Your local catalog
re-syncs from models.dev via stella models refresh.
Google Gemini
Gemini over the native generateContent API — the 1M-token context window, thinkingLevel mapped from Stella's effort setting, and gemini-3-pro as the default model.
Amazon Bedrock
Claude under AWS governance — SigV4-signed Bedrock Converse, cross-region inference profiles, and why this provider is deliberately last in auto-detection.