When `/v1/videos`, `/v1/videos/remix`, `/v1/videos/edit`, and `/v1/videos/extend` re-encode the returned video id, they resolve the deployment id like this in `litellm/proxy/video_endpoints/endpoints.py`:

```python model_id=hidden_params.get("model_id") or data.get("model"), ```

(five call sites: `video_generation`, `video_remix` x2, `video_edit`, `video_extension`).

For a proxy model group backed by multiple router deployments (for example an `azure/sora-2` group with several deployments, each holding its own `api_key`/`api_base`, which is common with `STORE_MODEL_IN_DB` per-model keys), `data["model"]` at this point is still the client-supplied group/alias name, not the id of the specific deployment the router picked for this request. The router stamps the selected deployment's own `model_info.id` into `kwargs["litellm_metadata"]["model_info"]["id"]` when it builds the call (`_update_kwargs_with_deployment` in `litellm/router.py`), and that deployment id is what should be encoded, not the group name.

`hidden_params.get("model_id")` is usually populated from that same deployment id, but it is not guaranteed on every response type. `LiteLLMLoggingObj`'s cost calculator in `lite…