fix(proxy): recognize *.cognitiveservices.azure.com as OpenAI-compatible in pass-through cost tracking

[8FAX]

Re-opening #29726 against `litellm_oss_branch` from the start so the cosmetic `Verify PR source branch` check (sticky from the original `main`-targeted PR) doesn't shadow the real CI signal. Same diff, same tests — just a clean slate.

Summary

Azure OpenAI resources created via the newer "Azure AI Foundry" / Cognitive Services pathway live on `*.cognitiveservices.azure.com` subdomains, not the older `openai.azure.com`. Both are valid Azure OpenAI surfaces in production today.

The OpenAI pass-through cost-tracking handler hard-codes only the older hostname in five places:

• 4× `OpenAIPassthroughLoggingHandler.is_openai_*_route` static methods (chat completions, image generation, image editing, responses) in `openai_passthrough_logging_handler.py`
• 1× `PassThroughEndpointLogging.is_openai_route` in `success_handler.py`

As a result, calls from newer Azure deployments are silently classified as "not an OpenAI route", the dispatch into the cost-tracking handler is skipped, and tokens / cost never get extracted into `LiteLLM_SpendLogs` — the row is written with `prompt_tokens=0, completion_tokens=0, spend=0, model='unknown'`.

Reproducer

Verified 2026-06-04 against a real Azure OpenAI deployment on `*.cognitiveservices.azure.com` proxied through LiteLLM v1.88.0.

```bash

With AZURE_API_BASE pointing to a *.cognitiveservices.azure.com resource:

curl -X POST "$LITELLM_PROXY/azure/openai/deployments/MY_DEPLOYMENT/chat/completions?api-version=2024-10-21" \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"messages":[{"role":"user","content":"hi"}], "max_tokens":5}'

Call succeeds, but the LiteLLM_SpendLogs row has:

prompt_tokens = 0

completion_tokens = 0

spend = 0

model = 'unknown'

Because is_openai_route() returns False on the new Azure hostname.

```

Fix

Factor the hostname check into a single helper `_is_openai_compatible_host` listing all three recognized surfaces (`api.openai.com`, `openai.azure.com`, `cognitiveservices.azure.com`), and have all five call sites delegate to it.

Purely additive — never weakens recognition for the originally-supported hostnames. Every test case that passed before continues to pass.

Tests

Adds `test_is_openai_route_recognizes_cognitiveservices_azure_com` that exercises all four `is_openai__route` static methods against `.cognitiveservices.azure.com` URLs:

• positive cases per route (chat completions, image generation, image editing, responses)
• a cross-route negative to confirm route-specific path matching still works on the new hostname

```
$ python -m pytest tests/test_litellm/proxy/pass_through_endpoints/llm_provider_handlers/test_openai_passthrough_logging_handler.py
24 passed in 2.08s
```

Checklist

• CLA signed
• At least 1 test added (`test_is_openai_route_recognizes_cognitiveservices_azure_com`)
• Unit tests pass: 24 passed in handler test file
• Ruff lint: `make lint-ruff` → all checks passed
• Black format-check on touched files: clean
• Scope isolated to one specific problem (hostname recognition)

Out of scope for this PR

Tracked separately in #29728: `openai_passthrough_handler` calls chat-completions `transform_response` on Responses API payloads, throws inside the dispatch, and drops the SpendLogs row entirely. The fix there is to use the existing `OpenAIResponsesAPIConfig.transform_response_api_response` for the `is_responses` branch.

The two PRs are independent (either is useful standalone) but pair naturally for full Azure OpenAI Responses-API cost tracking on the newer Azure resource subdomain.

[greptile-apps]

Greptile Summary

This PR fixes silent cost-tracking failures for Azure OpenAI resources deployed under *.cognitiveservices.azure.com by adding that hostname to the set recognized as OpenAI-compatible, consolidating the check into a single _is_openai_compatible_host helper.

• Introduces _OPENAI_COMPATIBLE_HOSTNAMES and _is_openai_compatible_host in openai_passthrough_logging_handler.py, then replaces all four duplicated hostname checks in is_openai_*_route with calls to it.
• Updates PassThroughEndpointLogging.is_openai_route in success_handler.py to delegate to the same helper via a local import (avoiding the existing circular-import constraint).
• Adds a focused test covering all four static methods against cognitiveservices.azure.com URLs, including cross-route negatives.

Confidence Score: 4/5

Safe to merge — the change is purely additive and the refactored helper is a faithful superset of the original logic.

The fix is isolated to cost-tracking hostname detection with no effect on authentication or request routing. The only gap is that test_is_openai_route_detection (which exercises PassThroughEndpointLogging.is_openai_route directly) was not extended with a cognitiveservices.azure.com positive case, leaving a small untested path through success_handler.py.

The test file is the only file worth a second look — test_is_openai_route_detection should be extended with a cognitiveservices.azure.com assertion to match the new coverage added for the static methods.

Important Files Changed

Filename	Overview
litellm/proxy/pass_through_endpoints/llm_provider_handlers/openai_passthrough_logging_handler.py	Extracts hostname matching into _is_openai_compatible_host and adds cognitiveservices.azure.com to the recognized set; all four is_openai_*_route static methods are updated consistently.
litellm/proxy/pass_through_endpoints/success_handler.py	Delegates is_openai_route to the shared _is_openai_compatible_host helper via a local import (avoiding circular imports); logic is equivalent to before, plus the new Azure hostname.
tests/test_litellm/proxy/pass_through_endpoints/llm_provider_handlers/test_openai_passthrough_logging_handler.py	Adds positive and cross-route negative cases for cognitiveservices.azure.com across all four static methods; test_is_openai_route_detection for PassThroughEndpointLogging.is_openai_route is not updated to cover the new hostname.

Comments Outside Diff (1)

1. tests/test_litellm/proxy/pass_through_endpoints/llm_provider_handlers/test_openai_passthrough_logging_handler.py, line 822-826 (link)

   The existing test_is_openai_route_detection test exercises PassThroughEndpointLogging.is_openai_route for api.openai.com and openai.azure.com, but never asserts True for the newly-added cognitiveservices.azure.com hostname. Since is_openai_route now delegates entirely to _is_openai_compatible_host, adding this case would close the small end-to-end coverage gap for that call path.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "fix(proxy): recognize *.cognitiveservice..." | Re-trigger Greptile}

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...der_handlers/openai_passthrough_logging_handler.py	88.88%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!