Azure OpenAI support conflates “deployment name” with “model name”

What version of Codex is running?

Latest main branch as of June 23, 2025

Which model were you using?

codex-mini

What platform is your computer?

Linux 5.15.146.1-microsoft-standard-WSL2 x86_64 x86_64

What steps can reproduce the bug?

1. Create an Azure OpenAI deployment of gpt-4o-mini with the name other-chat-model.
2. Configure the SDK/CLI with:

provider: azure
endpoint: https://<my-resource>.openai.azure.com/
api_key: $AZURE_OPENAI_API_KEY
model: other-chat-model

1. Start codex-cli and make any request (e.g. "Explain this codebase")
2. This results in the following user error: "Unsupported parameter: 'reasoning.effort' is not supported with this model"

There can also be scenarios where there is no service error, but the model may not behave as expected. For instance, a reasoning model with the deployment name that does not start with "o" may not have the reasoning effort set to the desired setting.

What is the expected behavior?

No logic should inspect the user’s deployment name when making assumptions about model capabilities.

What do you see instead?

See the repro steps for an example which will produce an error in the service (400/user error).

Another more subtle example is if a reasoning model (e.g. o4-mini, codex-mini) has a name like my-coding-model. In this case I can see from running in debug mode that the reasoning effort is not set at all which may result in unexpected behavior for users.

Additional information

Current Workaround

To ensure AOAI customers do not encounter unexpected service errors or behavior, they can ensure that their deployment names match standard OpenAI models names, e.g., o4-mini, codex-mini-latest, gpt-4.1. Most issues are likely avoided by ensuring that the deployment name uses the standard OpenAI model name as a prefix, e.g., o4-mini-reasoning-app.

Proposed Solution

• The Azure OpenAI codepaths need to have a concept of model and deployment name. The config needs to allow users to set both of these separately, e.g., model and deployment parameters.
• The logic that depends on the model name should use the model parameters, while the service request payload should use the deployment name. E.g., "model": "<deployment name>"