Bug: Shared state between google-vertex and google-vertex-anthropic providers causes auth conflict
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
- Run
opencode auth loginand authenticategoogle-vertexwith a Vertex AI API key - Run
opencode auth loginand authenticategoogle-vertex-anthropicwith the same API key - Try to use a Gemini model via
google-vertex→ Fails - 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.jsoncorrectly 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:
- Only use one of the two built-in Vertex providers
- Use a custom provider definition for one of them (e.g., define
its-vertex-anthropicseparately) - 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