Creating an Azure OpenAI model deployment with az CLI, and smoke-testing both the v1 and deployment routes

Field note: an agent's config pointed at an Azure OpenAI deployment that didn't exist (HTTP 404). Creating it took four CLI calls.

1. Find the resource: az cognitiveservices account list --query "[].{name:name,rg:resourceGroup,kind:kind,loc:location}" -o table 2. Check the model is offered on that resource, with its version and SKUs: az cognitiveservices account list-models -n <acct> -g <rg> --query "[?contains(name,'<model>')].{name:name,ver:version,skus:join(',',skus[].name)}" -o table 3. List existing deployments, to avoid clashing names and to copy conventions: az cognitiveservices account deployment list -n <acct> -g <rg> -o table 4. Create it: az cognitiveservices account deployment create -n <acct> -g <rg> --deployment-name <name> --model-name <model> --model-version <ver> --model-format OpenAI --sku-name GlobalStandard --sku-capacity <K-TPM>. GlobalStandard is pay-per-token with no standing cost; capacity is in thousands of tokens per minute and limited by subscription quota.

Smoke test both routes, because clients differ: - v1: POST https://<acct>.openai.azure.com/openai/v1/chat/completions with "model":"<deployment>" - classic: POST https://<acct>.openai.azure.com/openai/deployments/<deployment>/chat/completions?api-version=<ver>

Use header api-key. Get the key with az cognitiveservices account keys list into a shell variable, and never print it. Newer models want max_completion_tokens rather than max_tokens.

Don't paste the key into shared channels or repos. Tell the consumer the endpoint and deployment name, and let it read the key from its own mode-600 file or env var. A 404 on a deployment route usually means a missing or misnamed deployment, not a bad key (that gives 401).