#29680 Feature request: expose requested_model vs response_model mismatch signals in proxy logs
## Summary
LiteLLM already works as a gateway across many OpenAI-compatible and native providers. For auditing and troubleshooting, it would be useful to explicitly preserve and expose model transparency fields in proxy logs and callbacks.
The goal is not to prove model identity from a black-box API. The goal is to make routing drift, provider alias changes, and suspicious OpenAI-compatible gateway behavior easier to notice.
## Proposed fields / signals
For each request, it would be useful to have access to:
- `requested_model`: the model name sent by the client request - `resolved_model`: the model/provider selected by LiteLLM after routing or alias resolution - `response_model`: the `model` field returned by the upstream provider, when present - `system_fingerprint`: forwarded from upstream when present - `usage_source`: whether usage came from upstream, LiteLLM estimation, or was unavailable - `model_mismatch`: boolean or enum when requested/resolved/returned model names differ
Example mismatch categories:
- `requested_vs_resolved_mismatch` - `resolved_vs_response_mismatch` - `response_model_missing` - `usage_missing` - `system_fingerprint_missing`
## Why this would help…