Repository navigation
[Bug]: Foundry Router - gen_ai.response.model is not the served model #273
Description
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
- Clone the repo
- export BASE_URL=https://myfoundry.services.ai.azure.com/api/projects/defaultproject
- export MODEL_NAME=my-model-router-deployment
- 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
Activity
github-actions commentedon Sep 24, 2026
cc Hector Hernandez (@hectorhdzg) Jackson Weber (@JacksonWeber) Leighton Chen (@lzchen) Nev (@MSNev) Radhika Gupta (@rads-1996) Jeremy Voss (@jeremydvoss)
rads-1996 commentedon Sep 24, 2026
damien-claveau-amadeus-com Can you share a screenshot of the
ChatOpenAI()call you are making, do you haveinclude_response_headersset to True?github-actions commentedon Sep 24, 2026
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 commentedon Sep 24, 2026
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 commentedon Sep 24, 2026
Thanks for the response. Removing
needs-author-feedback.damien-claveau-amadeus-com commentedon Sep 24, 2026
Now testing with include_response_headers=False,
the spans are correct. Is this the expected behavior ?
rads-1996 commentedon Sep 24, 2026
No, setting the parameter to True should in fact fetch the served model from the header. Do you still have the
use_responses_apiset 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_apiset 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-modelin the microsoft-opentelemetry package, so we already have support there.github-actions commentedon Sep 24, 2026
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 commentedon Sep 25, 2026
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.
github-actions commentedon Sep 25, 2026
Thanks for the response. Removing
needs-author-feedback.rads-1996 commentedon Sep 25, 2026
damien-claveau-amadeus-com So it looks like this SDK is correctly honoring the
x-ms-served-model. The fix should be in the foundry SDK as it should correctly populate the served model in the router scenario. We can only intercept and pass the value of this header and populate the response model. Please raise this issue in the foundry SDK.github-actions commentedon Sep 25, 2026
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-25.
damien-claveau-amadeus-com commentedon Sep 25, 2026
I agree with you, it must be an issue upstream. Can you reproduce it ?
github-actions commentedon Sep 25, 2026
Thanks for the response. Removing
needs-author-feedback.rads-1996 commentedon Sep 25, 2026
I need to have the model router scenario to be able to reproduce this error. If I simply execute the sample you have shared with a model in my environment it works perfectly fine and the served model shows up in response.model attribute.
github-actions commentedon Sep 25, 2026
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-25.
github-actions commentedon Oct 3, 2026
damien-claveau-amadeus-com friendly reminder: we are still waiting for your feedback.
If we do not hear back within 7 more days, this issue may be closed automatically.
github-actions commentedon Oct 10, 2026
damien-claveau-amadeus-com we have not received the requested information within 14 days, so we are closing this issue for now.
If you still need help, please comment with the requested details and we can reopen it.