Which model should you actually pick?

Here is my rule, and I will defend it. Start on gpt-4.1. It handles the large majority of chat, extraction, summarization, and agent work, takes a million tokens of context, and costs a fraction of the frontier tier. Prove it fails before you upgrade. Most teams never need to.

When do you move up? Three cases. First, hard multi-step reasoning where the answer depends on the model working through steps it does not show you: math, planning, tricky debugging. That is o-series or GPT-5 territory. Second, cost pressure at high volume, where gpt-4.1-mini or gpt-4.1-nano shave the bill on simple classification and routing. Third, media, where you need Sora for video or an image model. Everything else, gpt-4.1 first.

When should you not jump to a reasoning model? When latency matters and the task is not actually multi-step. Reasoning models think before they answer, which adds seconds and bills you for tokens you never see. I have watched a team put o3 behind a live chat widget and wonder why every reply took nine seconds. The task was FAQ lookup. It should have been gpt-4.1-mini.

Your first call with the v1 API

Microsoft opened the v1 Azure OpenAI API in August 2025, and it is the path I use now. Two things changed that matter. You use the plain OpenAI() client instead of the Azure-specific AzureOpenAI() client, and you stop passing a dated api-version on every call. You point base_url at your resource with /openai/v1/ on the end, and for new work you call the Responses API, which Microsoft recommends over Chat Completions.

import os
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

# Entra ID auth, no static key. Role needed: Cognitive Services OpenAI User.
token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), 'https://ai.azure.com/.default'
)

client = OpenAI(
    base_url='https://my-foundry-resource.openai.azure.com/openai/v1/',
    api_key=token_provider,
)

resp = client.responses.create(
    model='gpt-4.1',   # this is your DEPLOYMENT name, not the catalog name
    input='Give me one sentence on why deployment names matter.',
)

print(resp.output_text)

Expected output: one sentence, for example: Deployment names matter because your code calls the deployment, not the underlying model, so a mismatch returns a 404 rather than a fallback.

Failure modes: if your deployment is named gpt41-prod but you pass model='gpt-4.1', you get the 404 DeploymentNotFound from the top of this post. Point the same code at an o-series deployment and add temperature=0.2 and you get a 400, because reasoning models reject that parameter.

Deployment types set the price, not the model

Same model, four ways to buy it. The deployment type you pick when you create the deployment decides how you are billed and how the request is routed. Part 6 goes deep on this; here is what you need to make a first choice.

One trap specific to provisioned throughput: on GPT-4.1 a provisioned deployment caps context under 128,000 tokens, and a longer request returns HTTP 400. If you need the full million-token window on a provisioned deployment, turn on spillover, which routes the oversized requests to a matching standard deployment. That is the kind of detail that only bites you in production.

What a request costs

Token pricing is where a model choice turns into a monthly number. On Global Standard, gpt-4.1 runs about 2.00 US dollars per million input tokens and 8.00 per million output tokens as I write this. Prices move and vary by region, so treat these as the shape, not a quote, and check the pricing page before you budget.

Responses API or Chat Completions?

You will see both APIs in Azure samples, and the split confuses people. Chat Completions is the older interface: you send a list of messages and get one reply. It still works, and every model here supports it. The Responses API is the newer one Microsoft steers new projects toward. It keeps the same message style but folds stateful multi-turn handling, background tasks, hosted tools, and remote MCP servers into one call.

My rule is short. New code starts on Responses. It is where new features land first, and the built-in state and tool calling save you from stitching that together by hand. Keep Chat Completions when you are calling a partner model that only speaks that syntax, when you are porting OpenAI code that already uses it and there is no reason to churn, or when a library you depend on has not moved yet. Do not rewrite a working Chat Completions service just to be current. Rewrite it when you need a Responses feature.

One practical difference to plan for: content filter results come back in a different shape. Chat Completions returns prompt_filter_results and content_filter_results fields, while the Responses API puts a top-level content_filters array on the response object. If you have logging or safety tooling reading those fields, it needs a change when you switch. Small edit, but the kind that slips through until a filtered response quietly breaks a downstream job.

Model retirements will bite you

Every model in the catalog has a lifecycle, and older snapshots carry retirement dates. When a version retires, deployments that pin it stop serving, and if you let Azure auto-upgrade you, your model can change under you between one week and the next. Both failure modes are real. I have been paged for each.

My practice: pin an explicit model version on every production deployment, subscribe to the retirement notices, and keep a newer version deployed in a staging project so the migration is a config flip, not a scramble. Preview models, the ones tagged Preview in the catalog, get upgraded on Microsoft schedule and should never sit behind production traffic. Check the retirements page each quarter and diff it against what you have deployed.

For contrast across clouds, the same model-choice problem on AWS is covered in the Bedrock model catalog part of the AWS series. The vendors differ in naming and lifecycle policy, but the discipline of pinning versions is identical.

Default to gpt-4.1, upgrade only on evidence

If you take one deployment away from this part, make it a gpt-4.1 deployment on Global Standard, called through the v1 API with the Responses call. It covers most of what a team needs, its million-token window removes a whole class of chunking work, and at real volumes it stays far cheaper than provisioned throughput. Move to a reasoning model when a task proves it needs steps, drop to mini or nano when volume proves you can, and pin your versions either way.

Deploy that model in a scratch project this week and run the code above against it. Next up, Part 4 opens the other half of the catalog, the partner and open models sold through Models-as-a-Service, and when it is worth reaching past the OpenAI family at all.

References

• Azure OpenAI in Microsoft Foundry Models v1 API, Microsoft Learn
• Foundry Models sold directly by Azure, Microsoft Learn
• Use the Azure OpenAI Responses API, Microsoft Learn
• Azure OpenAI Service pricing

The model families you can deploy

The catalog moves fast. As I write this in 2026, the OpenAI half of Foundry Models spans several families, and you rarely need most of them. Here is the shape of it, with the numbers that actually drive a choice: context window (how much you can send in) and max output (how much comes back in one call).

Numbers from the Foundry Models catalog. GPT-5 max output and the exact GPT-5 member list shift as new versions land, so treat the top row as a range and confirm on the catalog page before you commit.

The context window is the number worth staring at. GPT-4.1 accepts just over a million tokens, roughly eight times what GPT-4o takes. That is the difference between feeding a model a whole codebase or a long contract, versus chunking it. The reasoning o-series sits in the middle at 200,000, which is plenty for most agent loops.

Which model should you actually pick?

Here is my rule, and I will defend it. Start on gpt-4.1. It handles the large majority of chat, extraction, summarization, and agent work, takes a million tokens of context, and costs a fraction of the frontier tier. Prove it fails before you upgrade. Most teams never need to.

When do you move up? Three cases. First, hard multi-step reasoning where the answer depends on the model working through steps it does not show you: math, planning, tricky debugging. That is o-series or GPT-5 territory. Second, cost pressure at high volume, where gpt-4.1-mini or gpt-4.1-nano shave the bill on simple classification and routing. Third, media, where you need Sora for video or an image model. Everything else, gpt-4.1 first.

When should you not jump to a reasoning model? When latency matters and the task is not actually multi-step. Reasoning models think before they answer, which adds seconds and bills you for tokens you never see. I have watched a team put o3 behind a live chat widget and wonder why every reply took nine seconds. The task was FAQ lookup. It should have been gpt-4.1-mini.

Your first call with the v1 API

Microsoft opened the v1 Azure OpenAI API in August 2025, and it is the path I use now. Two things changed that matter. You use the plain OpenAI() client instead of the Azure-specific AzureOpenAI() client, and you stop passing a dated api-version on every call. You point base_url at your resource with /openai/v1/ on the end, and for new work you call the Responses API, which Microsoft recommends over Chat Completions.

import os
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

# Entra ID auth, no static key. Role needed: Cognitive Services OpenAI User.
token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), 'https://ai.azure.com/.default'
)

client = OpenAI(
    base_url='https://my-foundry-resource.openai.azure.com/openai/v1/',
    api_key=token_provider,
)

resp = client.responses.create(
    model='gpt-4.1',   # this is your DEPLOYMENT name, not the catalog name
    input='Give me one sentence on why deployment names matter.',
)

print(resp.output_text)

Expected output: one sentence, for example: Deployment names matter because your code calls the deployment, not the underlying model, so a mismatch returns a 404 rather than a fallback.

Failure modes: if your deployment is named gpt41-prod but you pass model='gpt-4.1', you get the 404 DeploymentNotFound from the top of this post. Point the same code at an o-series deployment and add temperature=0.2 and you get a 400, because reasoning models reject that parameter.

Deployment types set the price, not the model

Same model, four ways to buy it. The deployment type you pick when you create the deployment decides how you are billed and how the request is routed. Part 6 goes deep on this; here is what you need to make a first choice.

One trap specific to provisioned throughput: on GPT-4.1 a provisioned deployment caps context under 128,000 tokens, and a longer request returns HTTP 400. If you need the full million-token window on a provisioned deployment, turn on spillover, which routes the oversized requests to a matching standard deployment. That is the kind of detail that only bites you in production.

What a request costs

Token pricing is where a model choice turns into a monthly number. On Global Standard, gpt-4.1 runs about 2.00 US dollars per million input tokens and 8.00 per million output tokens as I write this. Prices move and vary by region, so treat these as the shape, not a quote, and check the pricing page before you budget.

Responses API or Chat Completions?

You will see both APIs in Azure samples, and the split confuses people. Chat Completions is the older interface: you send a list of messages and get one reply. It still works, and every model here supports it. The Responses API is the newer one Microsoft steers new projects toward. It keeps the same message style but folds stateful multi-turn handling, background tasks, hosted tools, and remote MCP servers into one call.

My rule is short. New code starts on Responses. It is where new features land first, and the built-in state and tool calling save you from stitching that together by hand. Keep Chat Completions when you are calling a partner model that only speaks that syntax, when you are porting OpenAI code that already uses it and there is no reason to churn, or when a library you depend on has not moved yet. Do not rewrite a working Chat Completions service just to be current. Rewrite it when you need a Responses feature.

One practical difference to plan for: content filter results come back in a different shape. Chat Completions returns prompt_filter_results and content_filter_results fields, while the Responses API puts a top-level content_filters array on the response object. If you have logging or safety tooling reading those fields, it needs a change when you switch. Small edit, but the kind that slips through until a filtered response quietly breaks a downstream job.

Model retirements will bite you

Every model in the catalog has a lifecycle, and older snapshots carry retirement dates. When a version retires, deployments that pin it stop serving, and if you let Azure auto-upgrade you, your model can change under you between one week and the next. Both failure modes are real. I have been paged for each.

My practice: pin an explicit model version on every production deployment, subscribe to the retirement notices, and keep a newer version deployed in a staging project so the migration is a config flip, not a scramble. Preview models, the ones tagged Preview in the catalog, get upgraded on Microsoft schedule and should never sit behind production traffic. Check the retirements page each quarter and diff it against what you have deployed.

For contrast across clouds, the same model-choice problem on AWS is covered in the Bedrock model catalog part of the AWS series. The vendors differ in naming and lifecycle policy, but the discipline of pinning versions is identical.

Default to gpt-4.1, upgrade only on evidence

If you take one deployment away from this part, make it a gpt-4.1 deployment on Global Standard, called through the v1 API with the Responses call. It covers most of what a team needs, its million-token window removes a whole class of chunking work, and at real volumes it stays far cheaper than provisioned throughput. Move to a reasoning model when a task proves it needs steps, drop to mini or nano when volume proves you can, and pin your versions either way.

Deploy that model in a scratch project this week and run the code above against it. Next up, Part 4 opens the other half of the catalog, the partner and open models sold through Models-as-a-Service, and when it is worth reaching past the OpenAI family at all.

References

• Azure OpenAI in Microsoft Foundry Models v1 API, Microsoft Learn
• Foundry Models sold directly by Azure, Microsoft Learn
• Use the Azure OpenAI Responses API, Microsoft Learn
• Azure OpenAI Service pricing

The first thing I check on any Azure OpenAI project I inherit is the client constructor. If it still reads AzureOpenAI(api_version='2024-something'), the team is at least one release behind the API Microsoft now recommends, and half the time they are passing a model name that no longer deploys. Azure OpenAI in Foundry Models is the set of OpenAI models you deploy and call inside a Foundry resource. That is the whole topic of this part: which models you actually get in 2026, how to pick one without guessing, and how the request leaves your code.

Point a fresh client at a resource that has no deployment yet and you meet the error that opens every Azure OpenAI project:

openai.NotFoundError: Error code: 404
{'error': {'code': 'DeploymentNotFound',
 'message': 'The API deployment for this resource does not exist.'}}

What Azure OpenAI in Foundry Models means

Foundry Models is the catalog that sits inside a Foundry resource. It has two halves. Models sold directly by Azure are billed and supported by Microsoft on Azure infrastructure, and that half is where the OpenAI models live: the GPT-5 series, GPT-4.1, GPT-4o, the o-series reasoning models, plus media models for image, audio, and video. The other half is a marketplace of partner and open models, which Part 4 covers. When people say Azure OpenAI, they mean the OpenAI models in that first half.

A term that trips people up: a model is the catalog entry (say gpt-4.1), and a deployment is the named instance you create from it inside your resource. You call the deployment name, not the catalog name. They can match, and I usually make them match, but nothing forces that. The 404 above happens because the code calls a deployment that was never created.

The model families you can deploy

The catalog moves fast. As I write this in 2026, the OpenAI half of Foundry Models spans several families, and you rarely need most of them. Here is the shape of it, with the numbers that actually drive a choice: context window (how much you can send in) and max output (how much comes back in one call).

Numbers from the Foundry Models catalog. GPT-5 max output and the exact GPT-5 member list shift as new versions land, so treat the top row as a range and confirm on the catalog page before you commit.

The context window is the number worth staring at. GPT-4.1 accepts just over a million tokens, roughly eight times what GPT-4o takes. That is the difference between feeding a model a whole codebase or a long contract, versus chunking it. The reasoning o-series sits in the middle at 200,000, which is plenty for most agent loops.

Which model should you actually pick?

Here is my rule, and I will defend it. Start on gpt-4.1. It handles the large majority of chat, extraction, summarization, and agent work, takes a million tokens of context, and costs a fraction of the frontier tier. Prove it fails before you upgrade. Most teams never need to.

When do you move up? Three cases. First, hard multi-step reasoning where the answer depends on the model working through steps it does not show you: math, planning, tricky debugging. That is o-series or GPT-5 territory. Second, cost pressure at high volume, where gpt-4.1-mini or gpt-4.1-nano shave the bill on simple classification and routing. Third, media, where you need Sora for video or an image model. Everything else, gpt-4.1 first.

When should you not jump to a reasoning model? When latency matters and the task is not actually multi-step. Reasoning models think before they answer, which adds seconds and bills you for tokens you never see. I have watched a team put o3 behind a live chat widget and wonder why every reply took nine seconds. The task was FAQ lookup. It should have been gpt-4.1-mini.

Your first call with the v1 API

Microsoft opened the v1 Azure OpenAI API in August 2025, and it is the path I use now. Two things changed that matter. You use the plain OpenAI() client instead of the Azure-specific AzureOpenAI() client, and you stop passing a dated api-version on every call. You point base_url at your resource with /openai/v1/ on the end, and for new work you call the Responses API, which Microsoft recommends over Chat Completions.

import os
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

# Entra ID auth, no static key. Role needed: Cognitive Services OpenAI User.
token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), 'https://ai.azure.com/.default'
)

client = OpenAI(
    base_url='https://my-foundry-resource.openai.azure.com/openai/v1/',
    api_key=token_provider,
)

resp = client.responses.create(
    model='gpt-4.1',   # this is your DEPLOYMENT name, not the catalog name
    input='Give me one sentence on why deployment names matter.',
)

print(resp.output_text)

Expected output: one sentence, for example: Deployment names matter because your code calls the deployment, not the underlying model, so a mismatch returns a 404 rather than a fallback.

Failure modes: if your deployment is named gpt41-prod but you pass model='gpt-4.1', you get the 404 DeploymentNotFound from the top of this post. Point the same code at an o-series deployment and add temperature=0.2 and you get a 400, because reasoning models reject that parameter.

Deployment types set the price, not the model

Same model, four ways to buy it. The deployment type you pick when you create the deployment decides how you are billed and how the request is routed. Part 6 goes deep on this; here is what you need to make a first choice.

One trap specific to provisioned throughput: on GPT-4.1 a provisioned deployment caps context under 128,000 tokens, and a longer request returns HTTP 400. If you need the full million-token window on a provisioned deployment, turn on spillover, which routes the oversized requests to a matching standard deployment. That is the kind of detail that only bites you in production.

What a request costs

Token pricing is where a model choice turns into a monthly number. On Global Standard, gpt-4.1 runs about 2.00 US dollars per million input tokens and 8.00 per million output tokens as I write this. Prices move and vary by region, so treat these as the shape, not a quote, and check the pricing page before you budget.

Responses API or Chat Completions?

You will see both APIs in Azure samples, and the split confuses people. Chat Completions is the older interface: you send a list of messages and get one reply. It still works, and every model here supports it. The Responses API is the newer one Microsoft steers new projects toward. It keeps the same message style but folds stateful multi-turn handling, background tasks, hosted tools, and remote MCP servers into one call.

My rule is short. New code starts on Responses. It is where new features land first, and the built-in state and tool calling save you from stitching that together by hand. Keep Chat Completions when you are calling a partner model that only speaks that syntax, when you are porting OpenAI code that already uses it and there is no reason to churn, or when a library you depend on has not moved yet. Do not rewrite a working Chat Completions service just to be current. Rewrite it when you need a Responses feature.

One practical difference to plan for: content filter results come back in a different shape. Chat Completions returns prompt_filter_results and content_filter_results fields, while the Responses API puts a top-level content_filters array on the response object. If you have logging or safety tooling reading those fields, it needs a change when you switch. Small edit, but the kind that slips through until a filtered response quietly breaks a downstream job.

Model retirements will bite you

Every model in the catalog has a lifecycle, and older snapshots carry retirement dates. When a version retires, deployments that pin it stop serving, and if you let Azure auto-upgrade you, your model can change under you between one week and the next. Both failure modes are real. I have been paged for each.

My practice: pin an explicit model version on every production deployment, subscribe to the retirement notices, and keep a newer version deployed in a staging project so the migration is a config flip, not a scramble. Preview models, the ones tagged Preview in the catalog, get upgraded on Microsoft schedule and should never sit behind production traffic. Check the retirements page each quarter and diff it against what you have deployed.

For contrast across clouds, the same model-choice problem on AWS is covered in the Bedrock model catalog part of the AWS series. The vendors differ in naming and lifecycle policy, but the discipline of pinning versions is identical.

Default to gpt-4.1, upgrade only on evidence

If you take one deployment away from this part, make it a gpt-4.1 deployment on Global Standard, called through the v1 API with the Responses call. It covers most of what a team needs, its million-token window removes a whole class of chunking work, and at real volumes it stays far cheaper than provisioned throughput. Move to a reasoning model when a task proves it needs steps, drop to mini or nano when volume proves you can, and pin your versions either way.

Deploy that model in a scratch project this week and run the code above against it. Next up, Part 4 opens the other half of the catalog, the partner and open models sold through Models-as-a-Service, and when it is worth reaching past the OpenAI family at all.

References

• Azure OpenAI in Microsoft Foundry Models v1 API, Microsoft Learn
• Foundry Models sold directly by Azure, Microsoft Learn
• Use the Azure OpenAI Responses API, Microsoft Learn
• Azure OpenAI Service pricing

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts