Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix Model alias for team can not be viewed via the UI or the API after creation. [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#26312•Fetched 2026-04-24 05:52:37
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
enseanensean
Participants
enseanensean

Root Cause

Possible root cause

Code Example

curl -s https://<PROXY_URL>/team/update \
   -H "Authorization: Bearer sk-<MASTER_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
     "team_id": "<TEAM_ID>",
     "litellm_model_aliases": {"my-alias": "gpt-4o"}
   }'

---

{
   "data": {
     "litellm_model_table": {
       "model_aliases": {
         "my-alias": "gpt-4o"
       }
     }
   }
 }

---

curl -s "https://<PROXY_URL>/team/info?team_id=<TEAM_ID>" \
 -H "Authorization: Bearer sk-<MASTER_KEY>"

---

{
 "team_info": {
   "team_alias": "my-team",
   "litellm_model_table": null
 }
}
RAW_BUFFERClick to expand / collapse

What happened?

After successfully setting model_aliases on a team via POST /team/update, the GET /team/info endpoint returns litellm_model_table: null, making it impossible to read back the configured model aliases.

The aliases do work for routing — requests using the alias are correctly forwarded to the target model. The issue is only with the /team/info read-back.

Steps to reproduce

  1. Update model aliases on a team:
 curl -s https://<PROXY_URL>/team/update \
   -H "Authorization: Bearer sk-<MASTER_KEY>" \
   -H "Content-Type: application/json" \
   -d '{
     "team_id": "<TEAM_ID>",
     "litellm_model_aliases": {"my-alias": "gpt-4o"}
   }'
  1. ✅ Update response correctly includes the aliases:
{
   "data": {
     "litellm_model_table": {
       "model_aliases": {
         "my-alias": "gpt-4o"
       }
     }
   }
 }
  1. Query team info:
curl -s "https://<PROXY_URL>/team/info?team_id=<TEAM_ID>" \
 -H "Authorization: Bearer sk-<MASTER_KEY>"
  1. ❌ litellm_model_table is null:
{
 "team_info": {
   "team_alias": "my-team",
   "litellm_model_table": null
 }
}

Expected behavior

GET /team/info should return the litellm_model_table with model_aliases that was persisted via /team/update.

Actual behavior

litellm_model_table is always null in the /team/info response, despite the data being correctly stored in the database (confirmed by routing working and /team/update returning it).

Possible root cause

The /team/info DB query likely does not eagerly load the related LiteLLM_ModelTable record, so the foreign key relationship is unresolved and serialized as null.

Environment

  • LiteLLM version: 1.83.12
  • Deployment: self-hosted proxy (Docker)

extent analysis

TL;DR

The issue can be resolved by modifying the /team/info endpoint to eagerly load the related LiteLLM_ModelTable record.

Guidance

  • Verify that the LiteLLM_ModelTable record is correctly stored in the database by checking the database directly.
  • Check the database query used by the /team/info endpoint to ensure it is not excluding the litellm_model_table field.
  • Modify the /team/info endpoint to include the litellm_model_table field in its response, possibly by using an eager loading mechanism.
  • Test the modified endpoint to ensure it returns the expected litellm_model_table data.

Example

No code example is provided as the issue does not include the specific code used by the /team/info endpoint.

Notes

The provided information suggests that the issue is related to the database query used by the /team/info endpoint, but without more details about the endpoint's implementation, it is difficult to provide a more specific solution.

Recommendation

Apply workaround: Modify the /team/info endpoint to eagerly load the related LiteLLM_ModelTable record, as this is likely to resolve the issue and allow the endpoint to return the expected data.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#permission error#memory optimization#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING