feat(ai): add Anthropic Vertex provider

[MichaelYochpaz]

Summary

Adds a built-in anthropic-vertex provider for Claude on Google Cloud Vertex AI.

The provider is a thin adapter: it constructs an AnthropicVertex SDK client, injects it into the existing Anthropic Messages streaming path, and reuses the shared Anthropic request/stream/tool/thinking/error handling.

Notes

• @anthropic-ai/vertex-sdk is lazy-loaded through the built-in provider registry so root imports do not load the Vertex SDK or its nested google-auth-library@9.x. For compiled Bun binaries, Anthropic Vertex is pre-registered through a Bun shim, matching the Bedrock pattern, so the binary embeds the provider instead of resolving the lazy relative import at runtime.
• Vertex model IDs are generated from the Anthropic catalog with documented Vertex filtering and @YYYYMMDD snapshot conversion.
• I set the default model to claude-opus-4-8 to align with the default for the Anthropic provider.
  However, I think claude-sonnet-4-6 should be a better default (for both Anthropic and Vertex providers) as it's cheaper while still very capable, serving as a good default. Happy to switch if agreed.
• I renamed the display labels to Vertex AI (Gemini) (the same pre-existing vertex provider) and Vertex AI (Anthropic) (new addition) so that the two Vertex-backed providers are easier to distinguish.
• Another change worth considering:
  anthropic-messages.ts still contains an older workaround for Anthropic SDK effort typing.
  The current SDK type already accepts "xhigh" and "max" in output_config.effort, so the special "xhigh" cast branch could likely be simplified to params.output_config = { effort: options.effort }.
  I left that out of this PR to keep the Vertex provider scoped and avoid changes to anthropic.ts, but it's something that's worth removing on a separate commit / PR.
• Model regeneration includes unrelated OpenRouter catalog drift (moonshotai/kimi-k2.6:free was removed upstream) and a corresponding one-line test update.
• Model regeneration includes unrelated catalog drift from live API data

Resolves #5082

[jimlloyd-mse]

Consider placing ANTHROPIC_VERTEX_PROJECT_ID first in precedence, for users that want both Gemini and Anthropic models via Vertex AI but with different projects.

[MichaelYochpaz]

Thanks for the feedback, what you propose does make sense, however this precedence order was taken from Anthropic's docs describing the precedence of these env vars Claude Code:

Claude Code uses ANTHROPIC_VERTEX_PROJECT_ID as the project ID for Vertex AI requests. The GCLOUD_PROJECT and GOOGLE_CLOUD_PROJECT environment variables and the credential file referenced by GOOGLE_APPLICATION_CREDENTIALS take precedence over it. If none of these are set, the project ID is resolved from your gcloud configuration or the attached service account.

Of course, we don't have to follow Claude Code's precedence, but then there's the edge case where users that have both env vars set to different values will get different GCP projects being used between Pi and Claude Code.

[jimlloyd-mse]

I also worked on this as it is a gating item preventing Pi from being used at my company. I asked Sonnet to compare the two implementation and this one is strictly better, with the one possible exception being the precedence of ANTHROPIC_VERTEX_PROJECT_ID noted above.

I look forward to this PR being approved and merged.

[jimlloyd-mse]

I set the default model to claude-opus-4-8 to align with the default for the Anthropic provider.
However, I think claude-sonnet-4-6 should be a better default (for both Anthropic and Vertex providers) as it's cheaper while still very capable, serving as a good default. Happy to switch if agreed.

I also believe sonnet-4-6 is the better default. Sonnet also says:

claude-sonnet-4-6 is the only non-Haiku model with a native "global" Vertex endpoint
date-free ID that's also in the interleaved-thinking allowlist, so it's a natural choice.

[kannon92]

I tried testing this PR. I pulled the branch and ran it but I hit the following error:

 Model: claude-sonnet-4-6                                                                                                                                                                                                                                                                 

                                                                                                                                                                                                                                                                                          
 hello                                                                                                                                                                                                                                                                                    
                                                                                                                                                                                                                                                                                          

 Error: ResolveMessage: Cannot find module './anthropic-vertex.ts' from '/$bunfs/root/pi'                                                                                                                                                                                                 

I mainly ran the build-binaries.sh and then ran the pi binary.

[MichaelYochpaz]

@kannon92 Good catch, thanks for testing.

I had verified this with pi-test.sh beforehand, but missed that the Bun-built binary has a separate packaging path that doesn’t exercise the same module loading behavior.

I’ve pushed a fix that mirrors the existing Bedrock binary shim: the Bun binary now pre-registers Anthropic Vertex instead of resolving the lazy relative import at runtime.

I also built the binary and tested it with Vertex, and it appears to work now. Please try again when you get a chance and let me know if you hit any other issues.

[drpaneas]

I tested the Vertex path locally and the direct one-shot flow works end to end:

pi --provider anthropic-vertex --model claude-opus-4-6 -p "Say exactly: ok" < /dev/null

A couple of things from working through a similar implementation here:

• the project/location/env resolution wants to live in one place across env-api-keys.ts, google-vertex.ts, and anthropic-vertex.ts. Duplicating that policy might cause drift and auth bugs in the future. No biggie for now if you wan t to keep the PR small.
• interactive mode was much easier to reason about once it showed provider/model instead of only Model: <id>, since claude-opus-4-6 alone does not tell you whether the session is on anthropic or anthropic-vertex.
• some catalog-valid Vertex Claude models can still be project-gated. For example, claude-fable-5 returned a Vertex 403 here until Anthropic publisher data sharing was enabled for the GCP project.

Overall this looks like the right direction 👍 thanks for working on it :)

[MichaelYochpaz]

@drpaneas Thanks for testing and providing feedback!

On your points:

1. I think it's better to keep it out of this PR. The two providers have slightly different env var sets (e.g., ANTHROPIC_VERTEX_PROJECT_ID) and different defaults (e.g., GOOGLE_CLOUD_LOCATION is required for google-vertex, but has a default global value for anthropic-vertex), so applying changes to the existing Gemini Vertex module adds regression risk. If added, I believe it'd be a better fit on a separate, focused PR.

2. The provider/model display ambiguity does exist, but it's not Vertex-specific.
   anthropic and anthropic-vertex just happen to share model IDs.
   Bedrock IDs, for example, are visually distinct, so it doesn't surface there.
   A general provider/model display in interactive mode would be a good improvement, but also probably not in the scope of this PR as it should be a feature to all providers.

3. I'm familiar with the error. However, I think just passing the raw Vertex error through is likely the right approach. The messages are descriptive enough, and trying to parse and remap them adds maintenance burden and risks of potential issues when the error code / format changes.

[MichaelYochpaz]

@badlogic Sorry for the tag, but this PR has been sitting for 3 weeks, with frequent changes to main causing conflicts that require resolving and retesting each time.

Would love to move it forward if possible, let me know if you need anything from my side :)

[major]

For what it's worth, I stacked this PR on origin/main (0.80.3) with some heavy rebasing and it's chugging along just fine with various anthropic models via vertex AI using creds from a JSON file. 👏 Context windows look right and I'm able to set the thinking modes just as I can in opencode.

[twoGiants]

@MichaelYochpaz needs another rebase 🙈

@badlogic would be great to have this, then I can drop my extension which copies many of your internals to work properly. Appreciate it 👍

[MichaelYochpaz]

I've rebased this onto the latest main and updated the implementation to match the current Pi architecture.

Changes since the previous version:

• Updated the implementation to match Pi’s current provider registry and scoped configuration patterns.
• Updated model generation to use models.dev’s specialized google-vertex-anthropic catalog, adding Sonnet 5 and Opus 5, plus a bounded Fable 5 fallback.
• Changed the Anthropic Vertex default to claude-opus-5.
• Added support for the new per-request custom fetch option.
• Updated the documentation and expanded tests for configuration resolution, generated models, actual Vertex requests, browser-safe imports, and Bun packaging.

npm run check, the full build, focused tests, and local release packaging pass. I also tested the packed Node CLI and standalone Bun binary against Vertex, including tool use.

The PR should now be ready for review again.

[drpaneas]

I just gave it a try and seems to work fine for me. Thanks @MichaelYochpaz 👍