Summary

openclaw onboard currently treats every *.services.ai.azure.com custom provider endpoint as Azure Responses and persists api: "openai-responses", even when the user selected OpenAI/chat-completions compatibility.

Why this is wrong

Microsoft's current docs say Azure v1 accepts both:

• https://<resource>.openai.azure.com/openai/v1/
• https://<resource>.services.ai.azure.com/openai/v1/

And they explicitly document chat-completions models from other providers like DeepSeek/Grok on Foundry endpoints:

• Azure v1 lifecycle docs: https://learn.microsoft.com/en-us/azure/foundry/openai/api-version-lifecycle
• Foundry endpoints docs: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/endpoints

Relevant docs points:

• the v1 docs say chat completions are supported for "models from other providers like DeepSeek and Grok"
• the v1 docs say base_url accepts both *.openai.azure.com/openai/v1/ and *.services.ai.azure.com/openai/v1/
• the Foundry endpoints docs show POST https://<resource>.services.ai.azure.com/openai/deployments/<deployment>/chat/completions?... for DeepSeek

Current bad codepath

• src/commands/onboard-custom.ts:38 matches both *.services.ai.azure.com and *.openai.azure.com in isAzureUrl()
• src/commands/onboard-custom.ts:681 then forces api: "openai-responses" for all of them, ignoring params.compatibility

User-visible failure

A valid Foundry services.ai.azure.com chat-completions endpoint can be onboarded successfully but persisted with the wrong runtime API shape. The first real model request then goes to /responses instead of the chat-completions route that host/model actually supports.

Expected behavior

• *.openai.azure.com Azure OpenAI endpoints can keep the current Responses-first path
• *.services.ai.azure.com should not be forced onto Responses solely based on hostname
• when the user selected OpenAI-compatible chat-completions, persist the matching runtime API shape instead of overriding it

Follow-up from

• PR fix(provider): tui/agent etc not working when azure openai endpoint is onboarded through custom provider #49543