[Bug]: Foundry Router - gen_ai.response.model is not the served model

[damien-claveau-amadeus-com]

Component

Distro

Description

Opening the issue here, while it could be originating from a change on the Foundry Responses API too.

As opposed to the evidences shown in this feature #234

... my Azure Foundry Project endpoint reports the model-router name (eg "model-router-2025-11-18") in the "x-ms-served-model" header
instead of the model selected for the generation ("gpt-5.6-sol-2026-07-09"),
which is correctly reported as "model_name" in the response body metadata.

The served model from headers taking precedence, the most important information is lost.

Expected Behavior

Expected : the span attribute gen_ai.response.model should contain the model actually inferred ("gpt-5.6-sol-2026-07-09" in my case)

In any case, I think the fix should be upstream (Foundry or opentelemetry-python-genai),
and not a local workaround in the current project.

Option #1 : Revert Foundry API (ModelRouterControls=V1Preview) to its initial contract and report the model actually inferred through the "x-ms-served-model" header :

no change to the current codebase
no change to the upstream contribution open-telemetry/opentelemetry-python-genai#305

Option #2 : Capture the model name from the response body in the upstream https://github.com/open-telemetry/opentelemetry-python-genai/blob/main/instrumentation/opentelemetry-instrumentation-genai-langchain/src/opentelemetry/instrumentation/genai/langchain/callback_handler.py#L537

Steps to Reproduce

1. Clone the repo
2. export BASE_URL=https://myfoundry.services.ai.azure.com/api/projects/defaultproject
3. export MODEL_NAME=my-model-router-deployment
4. uv run --with langchain-openai python samples/langchain/sample_foundry_responses_api.py

Environment

[project]
name = "microsoft-opentelemetry"
version = "1.3.9"

Additional Context

No response

[github-actions]

cc Hector Hernandez (@hectorhdzg) Jackson Weber (@JacksonWeber) Leighton Chen (@lzchen) Nev (@MSNev) Radhika Gupta (@rads-1996) Jeremy Voss (@jeremydvoss)

[rads-1996]

damien-claveau-amadeus-com Can you share a screenshot of the ChatOpenAI() call you are making, do you have include_response_headers set to True?

[github-actions]

damien-claveau-amadeus-com we need more information before we can continue working on this issue.

Please reply within 14 days. If we do not hear back, this issue may be closed automatically.

Marked as needs-author-feedback on 2026-09-24.

[damien-claveau-amadeus-com]

Hello, Yes, I have used the python script provided in the samples directory (and a small change for the authentication).
The targeted Foundry instance is in SwedenCentral.

[github-actions]

Thanks for the response. Removing needs-author-feedback.

[damien-claveau-amadeus-com]

Now testing with include_response_headers=False,
the spans are correct. Is this the expected behavior ?

[rads-1996]

Now testing with include_response_headers=False, the spans are correct. Is this the expected behavior ?

No, setting the parameter to True should in fact fetch the served model from the header. Do you still have the use_responses_api set to True or did you set it to False? Do you mind sharing a repro of the exact application code you are running, I will try to reproduce the issue.

Alternately, if you can the following debug logs with use_responses_api set to True and include_response_headers=True -

This will tell us exactly what foundry is returning in this header value. Also, we already respect the x-ms-served-model in the microsoft-opentelemetry package, so we already have support there.

[github-actions]

damien-claveau-amadeus-com we need more information before we can continue working on this issue.

Please reply within 14 days. If we do not hear back, this issue may be closed automatically.

Marked as needs-author-feedback on 2026-09-24.

[damien-claveau-amadeus-com]

Thank you for your support.
Please find attached the files relevant to this issue :

output.txt
deps.txt
sample_foundry_responses_api.py

Note that the served model snapshot is properly reported in the "model"&"model_name" fields, which is weird if this openai/openai-python#3271 is not yet released. The Model Router just adds an extra layer of complexity, unfortunately.