Fixes#17477
Guardrails couldn't access request headers (like User-Agent) on Bedrock
pass-through endpoints because headers were only stored in
data["proxy_server_request"]["headers"] but not in data["metadata"]["headers"]
where guardrails typically look for them.
This fix adds headers to metadata in add_litellm_data_to_request() so
guardrails can access User-Agent, API keys, and other header-based checks
on all endpoints including Bedrock pass-through.
Test added to verify headers are available in metadata for guardrails.
- Add 'mask' action to SUPPORTED_ON_FLAGGED_ACTIONS
- Automatically sanitizes sensitive content using masked_session_messages
- Allows requests to proceed with masked content instead of blocking
- Add MCP call support
- Add pre_mcp_call and during_mcp_call to supported_event_hooks
- Verify mcp_call is supported in call_type Literal types
- Control exception details based on config
- Conditionally include scanners/evidence in exceptions based on
include_scanners and include_evidence settings
- Reduces payload size when detailed exception info isn't needed
- Add comprehensive test coverage
- Tests for masking functionality
- Tests for conditional exception details
- Tests for MCP call support
- Update documentation
- Add Mask section explaining masking functionality
- Clarify exception details control
All changes maintain backward compatibility.
extract model id from vertex ai passthrough routes that follow the pattern:
/vertex_ai/*/models/{model_id}:*
the model extraction now handles vertex ai routes by regex matching the model
segment from the url path, which allows proper model identification for
authentication and authorization in proxy pass-through endpoints.
adds comprehensive test coverage for vertex ai model extraction including:
- various vertex api versions (v1, v1beta1)
- different locations (us-central1, asia-southeast1)
- model names with special suffixes (gemini-1.5-pro, gemini-2.0-flash)
- precedence verification (request body model over url)
- non-vertex route isolation
* fix(gemini): use JSON instead of form-data for image edit requests
Gemini's image edit API expects JSON body, not multipart/form-data.
The handler was sending form-encoded data which caused 400 errors:
"Invalid JSON payload received. Unexpected token."
Changes:
- Add use_multipart_form_data() method to BaseImageEditConfig (default True)
- Modify image_edit_handler to use json= when use_multipart_form_data() is False
- Override use_multipart_form_data() in GeminiImageEditConfig to return False
* test(gemini): add test for use_multipart_form_data
Claude 3.7 Sonnet's default max_output_tokens is 64000, not 128000.
The 128K output limit requires the beta header 'output-128k-2025-02-19'.
This fixes the integration test failure where requests with max_tokens=128000
were being rejected by the Anthropic API.
Fixes test_multiturn_tool_calls in test_anthropic_responses_api.py
* feat(custom_llm): add image_edit and aimage_edit support
Add support for image_edit and aimage_edit methods in CustomLLM class,
allowing users to implement custom image editing providers.
Changes:
- Add image_edit() and aimage_edit() methods to CustomLLM base class
- Add custom provider detection in litellm.image_edit() function
- Add tests for sync and async image_edit with custom handlers
* docs: add image_edit to CustomLLM documentation
- Add /v1/images/edits to supported routes
- Add Image Edit section with example
- Update Custom Handler Spec with image_edit methods
* fix(unified_guardrails.py): send all chunks on completion of final stream
* feat(generic_guardrail_api.py): handle tool call response on streaming LLM responses
* fix(anthropic/chat/guardrail_translation): initial commit adding anthropic tool response streaming guardrails
enables guardrail checks on tool response from llm's to work via `/v1/messages`
* feat(anthropic/): working guardrail checks on tool response from LLMs
ensures guardrail checks on anthropic /v1/messages works as expected
* feat(responses/guardrail_translation): support tool call response guardrails on streaming for /v1/responses
ensures complete coverage of tool call responses
* refactor(openai.py): refactor to use consistent pydantic model for responses api tool response on streaming
enables non-openai model tool call response to work correctly with guardrail checks on /v1/responses
* test: update tests
* fix: fix linting error
* fix: fix failing tests
* fix: fix import errors
* fix(openai/chat/guardrail_transformation): fix final chunk returned on streaming
* docs: add OpenAI-compatible API limitations for Anthropic thinking
Document the fundamental incompatibility between Anthropic extended
thinking and OpenAI-compatible API clients. Explains:
- Why thinking_blocks must be resent (stateless vs stateful APIs)
- OpenAI vs Anthropic architecture differences
- Solutions for client developers
* Update docs
* fix: auto-drop thinking param when thinking_blocks missing
When modify_params=True, LiteLLM now automatically drops the 'thinking'
param if the last assistant message with tool_calls is missing
thinking_blocks. This prevents the Anthropic error:
"Expected thinking or redacted_thinking, but found tool_use"
This workaround addresses the OpenAI-Anthropic API incompatibility where
OpenAI-compatible clients don't preserve thinking_blocks.
