bug: Azure DeepSeek V4 never selects the DeepSeek SDK adapter

Summary

Azure-hosted DeepSeek-V4-Pro and DeepSeek-V4-Flash deployments work through Chat Completions, but OpenCode's Azure provider cannot use the DeepSeek-specific AI SDK adapter. The models work only with their implicit default reasoning effort and custom reasoningEffort variants fail.

Environment

• OpenCode 1.18.18
• Windows 11
• Native azure provider with Azure AI Foundry DeepSeek V4 deployments
• Global Standard deployments; no custom proxy or API key in config

Reproduction

1. Deploy DeepSeek-V4-Pro or DeepSeek-V4-Flash in Azure AI Foundry.
2. Configure the model with options.useCompletionUrls: true so the base model uses Chat Completions.
3. Run the base model. It succeeds.
4. Add a model variant such as:

variants: {
  max: { reasoningEffort: max }
}

5. Run opencode run --model azure/deepseek-v4-pro:max Reply" with exactly "OK.

Actual behavior

The base model responds, but selecting a variant that passes reasoningEffort fails with a generic Azure server error. Direct Chat Completions calls to the same deployment accept reasoning_effort: max and return reasoning_content correctly.

Root cause

packages/opencode/src/provider/provider.ts selects only sdk.chat() or sdk.responses() for the Azure provider. However, the bundled @ai-sdk/azure provider also exposes sdk.deepseek(). That adapter handles DeepSeek Chat Completions semantics, including max_tokens, reasoning_effort, and reasoning_content required across reasoning/tool-call turns. OpenCode never selects it.

Expected behavior

Azure DeepSeek models should use sdk.deepseek(modelID) when available, while retaining explicit API-routing overrides for non-DeepSeek Azure deployments. This would allow DeepSeek low / high / max reasoning effort and preserve reasoning content correctly in agentic multi-turn/tool-call sessions.

Related

• #29776 and PR #29775 covered generic Azure partner-model Chat Completions routing, but the PR was closed unmerged and did not select the DeepSeek-specific adapter.
• #42147 covers Azure Responses API routing for OpenAI models.

No credentials, resource names, or request IDs are included in this report.

Start in packages/opencode/src/provider/provider.ts and inspect how the Azure provider chooses sdk.chat() or sdk.responses(). Compare that routing with the bundled @ai-sdk/azure sdk.deepseek() adapter, then run the reported Azure DeepSeek variant reproduction. Done means reasoningEffort variants work through the DeepSeek adapter while explicit routing overrides remain available for other Azure deployments.