fix: only tag selected deployment in access group creation

[hztBUAA]

Summary

Fixes #21544

POST /access_group/new and PUT /access_group/{name}/update previously only accepted model_names, which tagged all deployments sharing each model name. This was inconsistent with the UI, which targets a single deployment via PATCH /model/{model_id}/update.

This PR adds an optional model_ids parameter to both endpoints, allowing API callers to tag specific deployments by their unique model_id:

• When model_ids is provided, only those specific deployments are tagged (precise, matches UI behavior)
• When only model_names is provided, all deployments sharing each name are tagged (backward compatible)
• When both are provided, model_ids takes priority

Changes

• litellm/types/proxy/management_endpoints/model_management_endpoints.py: Made model_names optional, added model_ids field to NewModelGroupRequest, NewModelGroupResponse, and UpdateModelGroupRequest
• litellm/proxy/management_endpoints/model_access_group_management_endpoints.py: Added update_specific_deployments_with_access_group() helper that targets deployments by model_id via find_unique. Updated create_model_group and update_access_group to use model_ids when provided
• tests/test_litellm/proxy/management_endpoints/test_access_group_management.py: Added 5 new test cases covering model_ids targeting, backward compat with model_names, priority when both provided, validation errors

Example

# Before (tags ALL gpt-4o deployments)
curl -X POST '/access_group/new' -d '{
  "access_group": "prod",
  "model_names": ["gpt-4o"]
}'

# After (tags only the specific deployment)
curl -X POST '/access_group/new' -d '{
  "access_group": "prod",
  "model_ids": ["deployment-id-for-eastus"]
}'

Test plan

• model_ids targets only specified deployments (not all sharing the model_name)
• model_names backward compatibility preserved (tags all deployments)
• model_ids takes priority when both model_ids and model_names are provided
• Validation: at least one of model_names or model_ids must be provided
• Validation: non-existent model_id returns 400
• Existing duplicate access group test still passes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 20, 2026 5:55am

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[CLAassistant]

All committers have signed the CLA.

[greptile-apps]

Greptile Summary

Added optional model_ids parameter to access group endpoints (POST /access_group/new and PUT /access_group/{name}/update) for precise deployment targeting. Previously, these endpoints only accepted model_names, which tagged all deployments sharing each model name. This change aligns the API behavior with the UI, which targets single deployments via PATCH /model/{model_id}/update.

Key changes:

• Added update_specific_deployments_with_access_group() helper that uses find_unique to target deployments by their unique model_id
• Made model_names optional and added model_ids field to request/response type definitions
• When model_ids is provided, it takes priority over model_names for precise targeting
• When only model_names is provided, all deployments sharing each name are still tagged (backward compatible)
• Validation ensures at least one of model_names or model_ids must be provided
• Non-existent model_id returns 400 error with clear message

Test coverage:

• 5 new comprehensive test cases covering targeting behavior, backward compatibility, priority logic, and validation
• All tests use proper mocks and verify database query patterns

Confidence Score: 4/5

• Safe to merge with proper testing
• The implementation is well-structured with comprehensive test coverage. The backward compatibility is properly maintained. Score is 4 instead of 5 due to a performance consideration in the update endpoint that fetches all deployments without filtering.
• Pay attention to model_access_group_management_endpoints.py:603 where find_many() is called without filtering - this could be optimized for large deployments

Important Files Changed

Filename	Overview
litellm/types/proxy/management_endpoints/model_management_endpoints.py	Added optional model_ids field to type definitions for precise deployment targeting, maintaining backward compatibility with existing model_names field
litellm/proxy/management_endpoints/model_access_group_management_endpoints.py	Implemented update_specific_deployments_with_access_group() for model_id-based targeting; updated create/update endpoints to support both model_names (all deployments) and model_ids (specific deployments) with proper prioritization
tests/test_litellm/proxy/management_endpoints/test_access_group_management.py	Added 5 comprehensive test cases covering model_ids targeting, backward compatibility, priority logic, validation errors, and non-existent model_id handling

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Access Group Create/Update Request] --> B{Has model_ids?}
    B -->|Yes| C[use_model_ids = True]
    B -->|No| D{Has model_names?}
    D -->|Yes| E[use_model_ids = False]
    D -->|No| F[Return 400 Error]
    
    C --> G{use_model_ids?}
    E --> H[Validate models exist in router]
    H --> G
    
    G -->|True| I[update_specific_deployments_with_access_group]
    G -->|False| J[update_deployments_with_access_group]
    
    I --> K[For each model_id]
    K --> L[find_unique by model_id]
    L --> M{Deployment exists?}
    M -->|No| N[Return 400 Error]
    M -->|Yes| O[Add access_group to model_info]
    
    J --> P[For each model_name]
    P --> Q[find_many by model_name]
    Q --> R{Deployments found?}
    R -->|No| S[Return 400 Error]
    R -->|Yes| T[Add access_group to all matching deployments]
    
    O --> U[Update deployment in DB]
    T --> U
    U --> V[Clear cache and return response]

Loading

_{Last reviewed commit: 4f24533}

[greptile-apps]

_{3 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

litellm/proxy/management_endpoints/model_access_group_management_endpoints.py
For large deployments, fetching all rows without filtering could be inefficient. Consider filtering to only deployments that have this access_group in their model_info:

        all_deployments = await prisma_client.db.litellm_proxymodeltable.find_many(
            where={"model_info": {"contains": access_group}}
        )

Note: Verify if Prisma supports JSON field filtering for your database backend before implementing.