(fix) propagate x-litellm-model-id in responses #16986
Open
+359
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Title
Propagate model ID header (
x-litellm-model-id) on error responsesRelevant issues
Pre-Submission checklist
Please complete all items before asking a LiteLLM maintainer to review your PR
tests/litellm/directory, Adding at least 1 test is a hard requirement - see detailsmake test-unitType
Bug Fix
Changes
This PR ensures the
x-litellm-model-idheader is consistently returned on both successful and failed requests across all endpoints (/v1/chat/completions,/v1/responses,/v1/messages) for sync and streaming calls.Previously, the model ID header was only returned on successful requests, and only for chat completions + responses API. It was missing on messages entirely, and responses API streaming as well, as well as error cases (non-200) for all the endpoints. This causes issues for clients who need to track which specific deployment handled their request, especially when debugging errors / tracking for metrics!
The fix extracts the model_id from the router's metadata (
litellm_metadata) which is populated during routing and persists throughout the request lifecycle, including when errors occur after a deployment has been selected. This ensures consistent behavior across all response types (success, streaming, and error).Test Results
Passing unit test screenshot:

Start the server:
/v1/chat/completionsSuccess - Non-streaming:
Success - Streaming:
Error - Bad Request:
Error - Streaming Bad Request:
Success - Non-streaming - Cross-provider to Bedrock:
Success - Streaming - Cross-provider to Bedrock:
Error - Bad Request - Cross-provider to Bedrock:
Error - Streaming Bad Request - Cross-provider to Bedrock:
/v1/messagesSuccess - Non-streaming:
Success - Streaming:
Error - Bad Request:
Error - Streaming Bad Request:
Success - Non-streaming - Cross-provider from OpenAI:
Success - Streaming - Cross-provider from OpenAI:
Error - Bad Request - Cross-provider from OpenAI:
Error - Streaming Bad Request - Cross-provider from OpenAI:
/v1/responsesSuccess - Non-streaming:
Success - Streaming:
Error - Bad Request:
Error - Streaming Bad Request:
Success - Non-streaming - Cross-provider to Bedrock:
Success - Streaming - Cross-provider to Bedrock:
Error - Bad Request - Cross-provider to Bedrock:
Error - Streaming Bad Request - Cross-provider to Bedrock: