Bug: Shared state between google-vertex and google-vertex-anthropic providers causes auth conflict #7514

Description

When using the same API key for both google-vertex and google-vertex-anthropic providers, only the last authenticated provider works. The other provider fails, even though both are correctly configured in auth.json.

Steps to Reproduce

1. Run opencode auth login and authenticate google-vertex with a Vertex AI API key
2. Run opencode auth login and authenticate google-vertex-anthropic with the same API key
3. Try to use a Gemini model via google-vertex → Fails
4. Claude models via google-vertex-anthropic → Works

If you reverse the order (authenticate google-vertex-anthropic first, then google-vertex):

• Gemini via google-vertex → Works
• Claude via google-vertex-anthropic → Fails with error like:

  Publisher Model `projects/<project>/locations/global/publishers/google/models/claude-opus-4-5@20251101` not found.
  

Expected Behavior

Both providers should work independently. The same API key should be usable for both Gemini and Claude models on Vertex AI, as they are separate provider configurations.

Actual Behavior

Whichever provider is authenticated last wins. The other provider breaks, suggesting shared global state between the two providers.

Environment

• auth.json correctly stores separate entries for each provider:

{
  "google-vertex-anthropic": {
    "type": "api",
    "key": "AIzaSy..."
  },
  "google-vertex": {
    "type": "api",
    "key": "AIzaSy..."
  }
}

Analysis

The issue appears to be that OpenCode (or the underlying @ai-sdk/google-vertex SDK) initializes a shared singleton client when an API key is provided. The last authentication overwrites this shared state, breaking the previously authenticated provider.

Each provider should have its own isolated SDK instance to prevent this conflict.

Workaround

Currently, users must either:

1. Only use one of the two built-in Vertex providers
2. Use a custom provider definition for one of them (e.g., define its-vertex-anthropic separately)
3. Use ADC (Application Default Credentials) instead of API keys

Additional Context

• The same API key works for both Gemini and Claude when tested individually
• The issue is specifically about shared runtime state, not the stored credentials