Plan: one Vertex provider for every publisher (#76)

Developers configure Claude on Vertex one way — a config file with a region pinned per model, a probe that finds what their project can call, ADC retry on reauth — and were about to configure Gemini a second way (env vars or /login) because pi happens to ship a google-vertex provider. Two styles for one platform is an anti-pattern, and the operator has said every MaaS model on Vertex is coming through the same door. So the extension becomes generic: a model entry names its publisher kind, each kind is registered under its own provider id from the same file, and each kind delegates the wire protocol to code that already exists — the Anthropic SDK today, pi-ai’s api/google-vertex for Gemini (it takes project and location per call), pi-ai’s api/openai-completions for MaaS (Vertex’s OpenAI-compatible endpoint takes an ADC bearer). Packaged defaults are pinned from the 2026-09-07 probe so it works on install with the ADC every developer already has; the probe regenerates them for any other project.

Publisher kinds, not providers, are the schema. An entry gains publisher: "anthropic" | "google" | "openai-compatible" (default anthropic, so every existing file is valid unchanged). The extension registers one provider id per kind present in the file: vertex-anthropic, vertex-gemini, vertex-maas. A fourth kind later is a fourth branch and a fourth id, not a new configuration style.

pi-facing id and Vertex id are separate fields. MaaS model strings carry a slash (openai/gpt-oss-120b-maas); pi refs are provider/id and several parsers split at the first slash. An entry has id (pi-facing, no slash) and optional vertexModel (the publisher path Vertex wants, when it differs). Anthropic and Gemini entries omit it.

Delegate the wire, own the routing — through the alias surface only. pi resolves @earendil-works/* for an installed extension through a fixed map: package roots, /compat, /oauth, /providers/all (index.ts, "EXTENSION ALIAS SURFACE"). Deep subpaths such as pi-ai/api/google-vertex resolve in the workspace and break in a real install, so they are not used. The google kind takes the built-in google-vertex Provider from builtinProviders() in @earendil-works/pi-ai/providers/all and calls its streamSimple with options.env = { GOOGLE_CLOUD_PROJECT: project, GOOGLE_CLOUD_LOCATION: entry.region } — the same channel pi uses to hand a stored credential’s env to that adapter — and NO apiKey (the adapter would take one as a Vertex API key and skip ADC). Proven 2026-09-07 with no env set: gemini-3.8-flash at global answered; the same model at us-east5 returned 404, so the pin is real and its failure is loud. The openai-compatible kind calls streamSimple from @earendil-works/pi-ai/compat (after registerBuiltInApiProviders()) with the model re-tagged api: "openai-completions", baseUrl set to https://<host>/v1/projects/<project>/locations/<region>/endpoints/openapi (host aiplatform.googleapis.com for global, <region>-aiplatform… otherwise) and apiKey set to a live ADC access token. Proven the same day: openai/gpt-oss-120b-maas answered, and pi-ai surfaced its reasoning as a thinking block. The anthropic kind is untouched.

Availability without a login. pi shows a provider’s models only when it is "configured"; the current oauth sentinel needs a one-time /login per provider id, which would be three logins. Each kind registers with a literal apiKey: "adc" placeholder instead — pi’s documented way to mark a keyless provider configured — so every kind appears in /model on install. No kind ever forwards that placeholder: anthropic ignores it (own client), google strips it, maas replaces it with the bearer. The existing vertex-anthropic oauth record in a developer’s auth.json stays harmless. Step 0 proves the placeholder route before anything is built on it.

Erratum (2026-09-07): the placeholder key is declared beside the oauth sentinel, not instead of it — with a pre-publisher login record in auth.json and no oauth block declared, pi lets the stored record win and the provider vanishes from /model (observed against consumer-sim’s staged install); with both declared, both agent-dir states resolve.

Defaults come from the catalogue that knows, read at runtime. For a google entry whose id the installed pi-ai’s Vertex catalogue lists (builtinProviders() → google-vertex → getModels(), so the operator’s pi, not the workspace’s, is the source: 0.85.1 lists gemini-3.8-flash with thinkingLevelMap { off: null }; 0.84.3 does not), contextWindow, maxTokens, cost and thinkingLevelMap default from that entry; the file overrides. An id the catalogue lacks gets the file’s values or the extension’s defaults, as Anthropic entries do; nothing is synthesized from a neighbour.

No packaged entry without a real rate. unit.test.ts today requires a cost block on every catalogue entry and checks Anthropic’s multipliers (5x output, 1.25x cache write, 0.1x cache read) on all of them. The "every entry has rates" half stays universal — a zero-cost entry misreports session cost forever; the multiplier half is scoped to the anthropic kind. Google rates come from Google’s published Vertex pricing (pi-ai’s catalogue carries them for listed ids); MaaS rates come from the Vertex Model Garden pricing page at probe date, cited in the //cost note. A MaaS model whose price cannot be found is NOT shipped in the packaged file — the probe still finds it for anyone who wants it in their own.

Thinking per kind. anthropic keeps thinking: adaptive|budget|none. google maps pi’s reasoning level through pi-ai’s adapter (LOW/MEDIUM/ HIGH; the catalogue’s thinkingLevelMap says which a model lacks). openai-compatible passes reasoning through pi-ai’s completions adapter (reasoning_effort). A vendor that ignores that field answers 200 without reasoning — silent, so it is not left to chance: a packaged MaaS entry is marked reasoning: true only when the probe observed a thinking block in its reply (gpt-oss did), otherwise reasoning: false, and the page lists which is which.

The config file is renamed. vertex-anthropic-models.json becomes vertex-models.json and $VERTEX_ANTHROPIC_CONFIG becomes $VERTEX_CONFIG. Pre-1.0, callers move with the code: no detection of the old name, no shim; the changelog entry leads with the rename and an operator with an override file renames it.

Package name stays this step. @gadhs/pi-vertex-anthropic is a misnomer once it serves three publishers, but the rename churns the registry, the meta package and every doc; it is its own issue (#77), the operator’s call, and this plan does not depend on it.

pi’s built-in google-vertex is left alone. A developer who also sets its env vars sees Gemini twice under two ids. Documented, not suppressed: the package does not reach into pi’s providers.

ADC retry is shared; the bearer refresh is the attempt’s. The pump that survives a mid-session reauth (pumpWithAdcRetry, which waits intervalMs between tries) wraps every kind unchanged. For maas the token is fetched inside the attempt factory, so each retry picks up a rotated credential; a 401 on a cached token forces one immediate refetch inside the same attempt before the pump’s wait applies — the only place an immediate refetch lives.