fix(proxy): keep the model-group alias through vector store credential merges

[mateo-berri]

Relevant issues

Fixes #36103

What this does

Since #24548, get_deployment_credentials_with_provider unconditionally injects the deployment's litellm_params.model into the returned credentials. The router-bound merge sites in the vector store files endpoints copied that dict over data, so requests left the endpoint carrying the underlying provider model instead of the alias the caller named. In route_request the underlying model matches llm_router.deployment_names, which dispatches with specific_deployment=True and skips access-group filtering entirely, so when several model groups share one litellm_params.model (different access groups, team scoping, per-group settings) the request can be served under the wrong group and spend/logs attribute to it.

The fix adds a routing_model parameter to prepare_data_with_credentials and passes the resolved alias at the three router-bound merge sites in litellm/proxy/vector_store_files_endpoints/endpoints.py (unified vector store id path, model-hint path, single-OpenAI-team-deployment fallback). Direct-to-SDK call sites (batches, files) don't pass it and keep receiving the underlying model, so the #25104 fix from #24548 is preserved; a test pins each behavior.

Test coverage

• TestPrepareDataWithCredentials::test_routing_model_keeps_alias_over_credentials_model — alias survives the merge when two groups share one provider model
• TestPrepareDataWithCredentials::test_credentials_model_lands_in_data_without_routing_model — direct-to-SDK sites still get the deployment model (Bedrock batch inference broken via proxy: credential fields and model silently dropped #25104)
• Updated the tenant-guard and vector store endpoint tests to assert the alias reaches dispatch instead of the underlying model

uv run pytest tests/test_litellm/proxy/vector_store_endpoints/ tests/test_litellm/proxy/test_model_based_routing_files_batches.py tests/test_litellm/proxy/batches_endpoints/ tests/test_litellm/proxy/test_batch_x_litellm_model_encoding.py tests/test_litellm/proxy/openai_files_endpoint/ — 244 passed

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

The PR adds an optional routing-model override to credential merging so router-bound vector-store requests retain their model-group alias while direct SDK paths keep the provider model.

• Extends prepare_data_with_credentials with routing_model.
• Applies alias preservation to unified managed-file IDs, explicit model hints, and inferred single-team OpenAI deployments.
• Updates focused unit and endpoint assertions for the intended routing behavior.

Confidence Score: 3/5

The PR should not merge until alias preservation also covers the legacy simple encoded-file path; the newly added test comments are non-blocking cleanup.

Router-bound vector-store operations using legacy encoded file IDs still merge credentials without restoring the resolved alias, allowing dispatch to proceed under the underlying deployment identity instead.

Files Needing Attention: litellm/proxy/vector_store_files_endpoints/endpoints.py and the modified vector-store endpoint tests

Security Review

The alias-preserving merge remains absent from the legacy simple encoded-file path, so that router-bound path can still lose its routing identity.

Important Files Changed

Filename	Overview
litellm/proxy/openai_files_endpoints/common_utils.py	Adds a backward-compatible routing_model override while retaining the existing provider-model behavior for callers that omit it.
litellm/proxy/vector_store_files_endpoints/endpoints.py	Preserves aliases at three merge sites but misses the router-bound simple encoded-file branch.
tests/test_litellm/proxy/test_model_based_routing_files_batches.py	Covers both alias-preserving and legacy provider-model credential merges without real network calls.
tests/test_litellm/proxy/vector_store_endpoints/test_vector_store_endpoints.py	Updates model-hint and team-fallback expectations correctly, but adds comments prohibited by repository guidance.
tests/test_litellm/proxy/vector_store_endpoints/test_vector_store_tenant_guard.py	Updates the unified managed-vector-store assertion correctly, but adds a prohibited explanatory comment.

_{Reviews (1): Last reviewed commit: "fix(proxy): keep the model-group alias t..." | Re-trigger Greptile}

[greptile-apps]

Legacy IDs still lose aliases

When a vector-store operation uses a simple encoded file ID containing a model-group alias, the sibling branch merges credentials without passing model_used as routing_model. This replaces the alias with the underlying deployment model, causing incorrect group routing and attribution or a model-not-found response. How this was verified: The encoded-ID branch flows into router dispatch without any later assignment restoring model_used after the credential merge.

Rule Used: What: For security fix PRs, NEVER mention what sec... (source)

Knowledge Base Used: Proxy Server Request Flow

[greptile-apps]

New comments violate repository guidance

This change adds explanatory inline comments here and at the other modified alias-routing assertions, despite the repository instruction prohibiting new comments unless explicitly requested. Remove the four redundant comments while retaining the assertions.

Context Used: CLAUDE.md (source)

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!

[codecov]

Codecov Report

❌ Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...lm/proxy/vector_store_files_endpoints/endpoints.py	0.00%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[devin-ai-integration]

🚅 Hi, thanks for the PR! I'm Agent Shin, the automated triage bot for this repository. What's this and why am I getting it?

I read the description against our contribution rubric. Here's how it lined up:

What you got right:

• ✅ Linked a related GitHub issue
• ✅ Clear problem description
• ✅ Expected vs. actual behavior

What's still missing:

• End-to-end QA proof: the only evidence is uv run pytest ... 244 passed, which mocks the router and providers, so it never shows the alias reaching dispatch on a real proxy

The write-up and the linked issue are excellent, and the two named regression tests pin exactly the right behaviors. What is missing is one live run: a proxy with two model groups sharing a litellm_params.model, a vector store request naming the alias, and the log line showing the alias survived.

If the description isn't updated in the next 24 hours, I'll auto-close this PR. That's not us saying we don't care about the change; we want the open-PR list to mirror what a maintainer can act on right now, so contributors don't get lost in a backlog. A closed PR is a soft "park this for later," not a rejection. Take your time; everything below still works after the close.

During the grace period: just update the PR description with the missing pieces. No need to ping me; I'll re-check on the next sweep and skip the auto-close if it now passes. See what counts as QA proof for the full rubric (a linked issue alone isn't enough; it covers context, not proof).

If the PR does get auto-closed in 24 hours, you still have easy recovery paths:

• Comment @agent-shin reconsider after updating the description. I'll re-evaluate and reopen the PR if it now passes.
• Comment @greptileai to request a fresh Greptile review; that still works even after the PR is closed, and a stronger score is one of the signals that lifts the PR back into the queue. So a low Greptile score isn't a blocker either.

Internal BerriAI contributors: this rubric doesn't apply to you; ping a maintainer.

(I'm an LLM, so I'm not infallible. If you think I got this wrong, ping a maintainer; they'll override me.)

[devin-ai-integration]

🚅 Hi, thanks for the PR! I'm Agent Shin, the automated triage bot for this repository. What's this and why am I getting it?

I read the description against our contribution rubric. Here's how it lined up:

What you got right:

• ✅ Linked a related GitHub issue
• ✅ Clear problem description
• ✅ Expected vs. actual behavior

What's still missing:

• End-to-end QA proof: the only evidence is uv run pytest ... 244 passed from the repo's own unit tests, which mock the router, DB and provider.
• A Greptile confidence score of at least 4/5 (the latest review scored 3/5).

This is a routing/credential-merge fix on the live proxy path, so it is reproducible against a running proxy: two model groups sharing one litellm_params.model, a vector store request naming the alias, and the resolved model that reaches dispatch (or the spend log attribution) before and after the change. Paste those requests and their real responses and I will reopen. I warned about this on 2026-08-19 and the description has not changed since.

Closing this PR isn't a rejection of the change. We want the open-PR list to mirror what a maintainer can act on right now, so contributors don't get lost in a backlog. A closed PR is a soft "park this for later"; your work is still here, the diff is still here, and getting it reopened is one comment away. Take your time.

To bring this PR back:

• Update the description with the missing pieces, then comment @agent-shin reconsider on this PR. I'll re-evaluate and reopen if it now passes.
• Or Open a new PR with the same fix and the updated description. GitHub doesn't always let external contributors reopen a bot-closed PR, so a fresh PR is the most reliable path back into the review queue.
• If Greptile's most recent score on this PR was below 4/5, comment @greptileai to request a fresh review; that still works even after the PR is closed, and a stronger score is one of the signals that lifts the PR back into the queue. A low Greptile score isn't a blocker.

What "end-to-end QA proof" means, since it's the most common gap: at least one of a short before/after screen recording / video (the bug reproducing, then the fix working; for a brand-new feature, a recording of it working end-to-end), a screenshot (or before/after screenshots) of it working, or the exact commands you ran paired with their real output against the real system. Running pytest on the repo's unit tests doesn't count; those mock the LLM provider, DB, and network, so they aren't end-to-end. Output from a real, no-mocks integration run is what we look for. A linked issue alone isn't enough either: it covers context, not proof. See the full rubric.

Internal BerriAI contributors: this rubric doesn't apply to you; ping a maintainer.

(I'm an LLM, so I'm not infallible. If you think I got this wrong, comment @agent-shin reconsider or ping a maintainer; they'll override me.)