Share via

Responses API returning deployment name instead of model name

Maissene Zairi 20 Reputation points
2026-01-02T10:30:45.2766667+00:00

Description

I am seeing an inconsistency between the Completions API and the Responses API in Azure OpenAI regarding the value returned in response.model.

  • Deployment name: gpt-5-01
  • Underlying model: gpt-5
  • Model version: 2025-08-07

When using the Completions API, the response correctly returns the underlying model identifier:

response.model = "gpt-5-2025-08-07"

However, when using the Responses API with the same deployment, the response returns only the deployment name.

response.model = "gpt-5-01"

Looking at the Responses API Documentation, the response should be the same as the completions API (actual model identifier)

This difference is problematic because:

  • It makes it impossible to reliably infer the actual model and version used from the Responses API output.
  • It breaks tooling that depends on the canonical model name, such as:
    • usage tracking and price calculation based on model/version (case I encountered with when using pydantic-ai / genai-prices libraries)
    • logging and analytics that expect stable model identifiers.

Given that the Completions API already returns the full model identifier for the same deployment, I would expect the Responses API to behave consistently, or for the documentation to clearly state that response.model will always be the deployment name.

Expected behavior

  • response.model should return the underlying model identifier (e.g. gpt-5-2025-08-07), or
  • the Responses API should expose the base model and version in a separate field.

Actual behavior

  • response.model returns only the deployment name (gpt-5-01) in the Responses API.

Please let me know if this is expected behavior by design, a known issue being tracked, or something that should be reported as a bug to the Azure OpenAI product team.

Azure OpenAI in Foundry Models

Answer accepted by question author

SRILAKSHMI C 18,745 Reputation points Microsoft External Staff Moderator
2026-01-06T12:12:32.3333333+00:00

Hello Maissene Zairi,

Welcome to Microsoft Q&A and Thank you for reaching out.

The inconsistency you’re seeing between the Completions API and the Responses API is understandable and a common point of confusion.

Clarification on behavior

In Azure OpenAI Service, this behavior is expected by design for the Responses API. Unlike the legacy Completions API, which still returns the canonical model identifier (for example, gpt-5-2025-08-07) for backward compatibility, the Responses API intentionally returns the deployment name (for example, gpt-5-01) in response.model.

Azure OpenAI is deployment-centric rather than model-centric. The deployment is treated as the stable contract because:

A deployment can be upgraded to a newer model or version without application changes

Billing, quotas, and access control are all tied to the deployment, not the base model

Returning the deployment name avoids breaking workloads when the underlying model changes

As a result, the Responses API does not guarantee exposure of the underlying model name or version, and response.model should be assumed to always represent the deployment in Azure OpenAI.

Impact and current limitation

You are absolutely correct that this creates challenges for:

Reliably inferring the actual model and version used

Tooling that depends on canonical model identifiers (usage tracking, pricing libraries, analytics, logging)

Maintaining behavioral parity with the Completions API

At this time:

  • The Responses API does not expose the base model or version in a separate response field
  • There is no supported way to retrieve the canonical model identifier directly from the Responses API output

Recommended approach

To work around this limitation in a supported way:

Track model/version metadata at deployment time Record which base model and version are associated with each deployment in your own configuration or metadata store.

Use deployment name as the primary identifier This aligns with how Azure handles billing, quotas, and lifecycle management.

Avoid relying on response.model for pricing or analytics by model version Instead, map usage and cost to the deployment.

You’re also right that the documentation is not explicit about this behavior. This is a documentation clarity gap, and it’s reasonable to report this as feedback or a feature request to the Azure OpenAI product team, especially given the impact on tooling and analytics workflows.

Please refer this

I Hope this helps. Do let me know if you have any further queries.

Thank you!

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.