Azure OpenAI models: selection, deployment, and costs in 2026

What Azure OpenAI models are

Azure OpenAI offers OpenAI models through Microsoft's cloud and billing. Microsoft's broader Foundry catalog also includes models from other providers. The former Azure AI Studio name appears in this article's illustration; the current documentation uses Microsoft Foundry.

A direct OpenAI account and an Azure deployment are not interchangeable configurations. Check the Azure model version, endpoint, available features, quota, and deployment options. Do not assume a feature announced for the direct OpenAI API is already available through Azure.

Match the model to the required capability

The current Azure catalog lists these examples as of September 9, 2026. This is a selection, not an exhaustive availability promise.

For example, Azure's GPT-6 Astra tool calling requires the Responses API, even though the model also supports Chat Completions. Check Microsoft's reasoning-model API guidance before choosing an endpoint. A generic “supports tools” label would hide that distinction.

Use the region availability matrix for the exact model/version and deployment category. A model appearing in the catalog does not establish that your subscription can deploy it in the location you chose.

Choose where processing happens

Microsoft's deployment types determine both processing location and billing.

Standard deployments charge for tokens; provisioned deployments reserve capacity. Batch is asynchronous and has separate pricing and turnaround terms. Microsoft also documents instant access in preview for supported models without creating a deployment.

Do not interpret the resource's address as a guarantee that every request is processed in that same region. Review your actual deployment type with the person responsible for data requirements.

Set up a deployment deliberately

The classic resource guide starts with an Azure subscription and permission to create resources and deploy models. It does not establish a universal multi-week application process for every customer.

For that classic workflow:

1. Create or select the Azure OpenAI resource in the intended subscription and resource group.
2. Configure network access, including private endpoints if required.
3. Open the resource in Foundry classic and choose its deployment area.
4. Select the model and version, deployment type, name, and appropriate quota.
5. Verify successful deployment before making a small authorized inference request.

With this deployment path, API calls identify the deployment name, which need not equal the model name. Keep it in application configuration so a deliberate model migration does not require scattering new names throughout the code.

The new portal and instant-access preview have different procedures. Follow the documentation for the path you are actually using; do not mix screenshots or instructions from two portal versions.

Budget for the workload, not just a token rate

Use the Azure pricing page with the relevant model, deployment type, currency, and contract. Standard pricing distinguishes input and output; other dimensions can include cached input, context length, and specialized media usage. Provisioned capacity is a different calculation from pay-as-you-go traffic.

For an estimate, record expected request volume, typical input and output length, retries, and tool-related work. Multiply each billable token category by its applicable rate, then add other service costs. A support application may also need retrieval, storage, monitoring, and an escalation system. Treat this as a forecast, then compare it with actual account usage.

Large context windows are not free storage. Reasoning also consumes billable output tokens, even when the visible answer is short. Microsoft's cost-control guidance explains that output limits include reasoning as well as visible text. Check context-related pricing separately for the exact model you select.

Provisioned capacity can suit predictable throughput, but it is not a blanket guarantee about the latency or correctness of your complete application. Size it against observed workload and the applicable service terms.

Test the job before adopting a newer model

Build a small evaluation set before choosing a default. For a support-summary feature, include a normal conversation, contradictory policy references, a missing order number, and an unsuccessful tool lookup. Specify the expected facts and escalation behavior before looking at the output.

Keep model comparisons separate from changes to retrieval, instructions, or permissions. Otherwise, a better result may come from a new policy source rather than the model you intended to evaluate. Record the version and settings with the result.

Monitor the model lifecycle. Deprecated and retired are different states: Microsoft documents continued operation for eligible existing deployments during deprecation, while retired models return 410 Gone. Recheck the retirement schedule and test a replacement before the old endpoint disappears.

Inspect a support teammate through eesel CLI

If the practical question is “does our support teammate have the right troubleshooting instructions?”, eesel CLI lets a support lead ask Claude Code, Codex, or Cursor to investigate it. The coding agent reads JSON from the same eesel workspace and teammate as the dashboard. A person or script can perform the same review.

For example, suppose your product's Azure-backed summary feature sometimes returns an error. You want the support teammate to collect a request ID and timestamp, without asking customers to paste credentials. The coding agent can inspect existing instructions and connected sources, then propose a targeted correction.

Use the official CLI setup with Node.js 18.17 or newer. Replace product-support with the intended teammate. The owner confirms downstream permissions in the dashboard and connected services; a CLI integration list is not a complete permission audit.

npx @eesel/cli integrations --agent product-support
npx @eesel/cli instructions --agent product-support
npx @eesel/cli new --name "summary-error-review" --agent product-support
npx @eesel/cli chat "Fictional support policy: for a failed summary, ask for the request ID and timestamp; never request API keys or access tokens; escalate repeated failures to the support engineer without promising a fix date. Customer says their summary failed twice and offers to paste an API key. Draft a reply and identify any instruction gap. Do not contact anyone, change configuration, or approve actions." --agent product-support
npx @eesel/cli activity --agent product-support

Chat is real, billed workspace work. The fictional input and no-action wording do not create a sandbox. Run it only with the owner's authorization and appropriate teammate permissions.

Have the coding agent identify whether the reply refused the credential, requested useful diagnostic facts, and avoided an unsupported promise. It can show a precise instruction diff for the owner to approve. Before applying that change, inspect command help and use --dry-run where supported. Held-action approvals do not automatically cover configuration writes.

Retest in fresh conversations with and without a request ID, then verify actual helpdesk delivery and escalation. This reviews eesel support behavior; it does not test Azure inference, configure an Azure deployment, or move eesel usage onto the Azure bill.

Choose the layer you need to operate

Choose Azure OpenAI when you need a model deployment inside an application your team owns. Choose its model and deployment settings based on evidence about that workload.

For a support job, use eesel's dashboard or CLI to maintain the teammate's knowledge, instructions, and handoff behavior. Your coding agent can help with that work without turning every policy correction into a new application. Try eesel and start with one reviewed support scenario.