Litellm oss staging 02 14 2026

[krrishdholakia]

Relevant issues

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 16, 2026 0:44am

[greptile-apps]

Greptile Overview

Greptile Summary

Large staging PR that introduces guardrail pipeline execution (ordered, conditional guardrail steps within policies), renames access_model_ids to access_model_names in the access group schema, adds Pyroscope continuous profiling support, S3 virtual-hosted-style URL support, list-format system content handling in the responses transformation bridge, enriched proxy admin auth context, and a comprehensive UI rewrite for Access Groups.

• Guardrail Pipelines: New PipelineExecutor enables sequential guardrail execution with conditional pass/fail actions (allow, block, next, modify_response). Integrated into ProxyLogging.pre_call_hook with pipeline-managed guardrails excluded from independent execution. Includes pipeline test endpoint, validation, and full type definitions.
• Access Groups rename: access_model_ids → access_model_names across Prisma schemas and backend endpoints. However, the UI still references access_model_ids in all TypeScript interfaces and components — this will break model data display in the dashboard.
• Pyroscope profiling: New _init_pyroscope() method on ProxyStartupEvent. Critical bug: missing return after the disabled check causes the function to always attempt pyroscope configuration.
• S3 virtual-hosted-style URLs: Adds s3_use_virtual_hosted_style option for S3 logging with bucket.endpoint/key URL format.
• Responses transformation: Fixes list-format system content extraction and Reasoning() serialization.
• Proxy admin auth: Enriches the early-return UserAPIKeyAuth for proxy admins with team, org, and end-user context.
• UI Access Groups: Full rewrite with React Query hooks, details page, create/edit modals, and comprehensive test coverage.

Confidence Score: 2/5

• This PR has two bugs that will cause runtime issues: a missing return in the Pyroscope init and a frontend/backend field name mismatch for access groups.
• Score of 2 reflects two confirmed bugs: (1) the _init_pyroscope function is missing a return statement after the disabled check, causing it to always attempt pyroscope configuration on every proxy startup, and (2) the backend renamed access_model_ids to access_model_names but all UI TypeScript interfaces and components still use the old name, which will silently break model data display. Additionally, the pipeline executor saves original_guardrails but never restores it.
• Pay close attention to litellm/proxy/proxy_server.py (missing return in _init_pyroscope), ui/litellm-dashboard/src/app/(dashboard)/hooks/accessGroups/useAccessGroups.ts and all access group UI files (field name mismatch), and litellm/proxy/policy_engine/pipeline_executor.py (metadata not restored).

Important Files Changed

Filename	Overview
litellm/proxy/proxy_server.py	Added Pyroscope initialization but has a critical missing return statement — the function runs the configuration code even when the feature is disabled.
litellm/proxy/policy_engine/pipeline_executor.py	New pipeline executor for sequential guardrail execution. Well-structured but original_guardrails metadata is saved but never restored after step execution.
ui/litellm-dashboard/src/app/(dashboard)/hooks/accessGroups/useAccessGroups.ts	TypeScript interface still uses access_model_ids while backend was renamed to access_model_names — will cause model data to silently be undefined in the UI.
litellm/proxy/auth/user_api_key_auth.py	Enriches proxy admin UserAPIKeyAuth return with team/org/user context fields. Straightforward and consistent with the existing non-admin code path.
litellm/proxy/utils.py	Adds pipeline execution integration to the pre-call hook and pipeline-managed guardrail skipping. Cleanly integrates with existing guardrail callback loop.
litellm/proxy/litellm_pre_call_utils.py	Extends policy resolution to include pipeline data in metadata and exclude pipeline-managed guardrails from the flat guardrails list.
litellm/integrations/s3_v2.py	Adds virtual-hosted-style URL support for S3. Clean implementation with proper protocol handling.
litellm/proxy/management_endpoints/access_group_endpoints.py	Renames access_model_ids to access_model_names and adds unique constraint handling for update. Backend change is clean but UI was not updated to match.
litellm/types/proxy/policy_engine/pipeline_types.py	Well-defined Pydantic models for pipeline types with proper validation on actions and modes.
litellm/proxy/policy_engine/policy_resolver.py	Adds pipeline resolution and managed guardrail extraction. Clean static methods that integrate with existing policy matching.
litellm/completion_extras/litellm_responses_transformation/transformation.py	Adds handling for list-format system message content blocks, extracting text parts into instructions. Correct fix for the responses transformation bridge.
litellm/proxy/schema.prisma	Adds pipeline JSON field to policy table and renames access_model_ids to access_model_names. Schema migration included.
litellm/proxy/policy_engine/policy_endpoints.py	Adds /policies/test-pipeline endpoint for testing guardrail pipelines. Well-structured with proper error handling.
litellm/responses/litellm_completion_transformation/transformation.py	Changes Reasoning() to dict(Reasoning()) and uses setattr for provider_specific_fields to avoid Pydantic validation issues.
litellm/proxy/pass_through_endpoints/pass_through_endpoints.py	Adds custom_body parameter to route handlers for signature compatibility and improves body forwarding logic.

Flowchart

flowchart TD
    A[Incoming Request] --> B[Policy Resolver]
    B --> C{Matching Policies<br/>with Pipelines?}
    C -->|No| D[Normal Guardrail Execution]
    C -->|Yes| E[Pipeline Executor]
    E --> F[Step 1: Run Guardrail]
    F --> G{Outcome?}
    G -->|Pass| H{on_pass action}
    G -->|Fail| I{on_fail action}
    H -->|allow| J[✅ Allow Request]
    H -->|next| K[Step N: Run Next Guardrail]
    H -->|block| L[❌ Block Request]
    H -->|modify_response| M[🔄 Modify Response]
    I -->|allow| J
    I -->|next| K
    I -->|block| L
    I -->|modify_response| M
    K --> G
    J --> N[Skip Pipeline-Managed<br/>Guardrails in Normal Loop]
    N --> D
    D --> O[Continue Request Processing]

Loading

_{Last reviewed commit: 495ce34}

[greptile-apps]

_{83 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Missing return when Pyroscope is disabled

The early-exit guard logs a debug message but never returns. The code falls through to the try: block and attempts import pyroscope even when LITELLM_ENABLE_PYROSCOPE is false. This means on every proxy startup (when pyroscope-io is not installed) a spurious ImportError warning is logged. If pyroscope-io is installed, it will attempt to configure Pyroscope (and raise ValueError for missing env vars) even though the feature is disabled.

Suggested change

	if not get_secret_bool("LITELLM_ENABLE_PYROSCOPE", False):
	verbose_proxy_logger.debug(
	"LiteLLM: Pyroscope profiling is disabled (set LITELLM_ENABLE_PYROSCOPE=true to enable)."
	)
	if not get_secret_bool("LITELLM_ENABLE_PYROSCOPE", False):
	verbose_proxy_logger.debug(
	"LiteLLM: Pyroscope profiling is disabled (set LITELLM_ENABLE_PYROSCOPE=true to enable)."
	)
	return

[greptile-apps]

Backend/UI field name mismatch

The backend schema and Python types were renamed from access_model_ids to access_model_names in this PR (see schema.prisma, litellm/types/access_group.py, and access_group_endpoints.py), but the UI AccessGroupResponse interface and all components that reference it still use access_model_ids. The API will return JSON with the key access_model_names, so access_model_ids will be undefined in the UI and model data will silently disappear.

This affects at least: useAccessGroups.ts, useCreateAccessGroup.ts, useEditAccessGroup.ts, AccessGroupsPage.tsx, AccessGroupsDetailsPage.tsx, AccessGroupEditModal.tsx, AccessGroupCreateModal.tsx, and their test files.

Suggested change

	access_model_ids: string[];
	access_model_names: string[];

[greptile-apps]

original_guardrails saved but never restored

original_guardrails is saved at line 156 but is never restored after the guardrail executes. This means data["metadata"]["guardrails"] remains set to [step.guardrail] after _run_step completes. In a multi-step pipeline, each step overwrites this value (which is fine since it's re-set per step), but after the pipeline finishes, the caller's metadata is left mutated. Although execute_steps copies data and data["metadata"] at the top level, _run_step receives and mutates the working copy's metadata without cleanup — and if the pipeline result returns modified_data, downstream code may receive metadata with a stale single-guardrail list instead of the original.

Consider adding a finally block to restore:

finally:
    if original_guardrails is not None:
        data["metadata"]["guardrails"] = original_guardrails
    elif "guardrails" in data.get("metadata", {}):
        del data["metadata"]["guardrails"]

[Sameerlite]

This is #21307 cleaner