This fix addresses the same issue that was resolved for OpenAI video in PR #16708.
The GeminiVideoConfig class was importing BaseVideoConfig only within TYPE_CHECKING,
causing it to be 'Any' at runtime. This prevented the async_transform_video_content_response
method from being available during video content downloads.
Changes:
- Moved BaseVideoConfig import from TYPE_CHECKING to top-level imports
- Added test_gemini_video_config_has_async_transform() to verify the fix
- Ensures GeminiVideoConfig properly inherits BaseVideoConfig at runtime
Fixes video generation errors for Gemini Veo models:
'GeminiVideoConfig' object has no attribute 'async_transform_video_content_response'
* Attempt CI/CD Fix
* Adding test for coverage
* Adding max depth to copilot and vertex
* Fixing mypy lint and docker database
* Fixing UI build issues
* Update playwright test
* though signature tool call id
* [stripe] refactor and tests
* [stripe] remove md and move to factory
* [stripe] remove redudant test
* [stripe] ran black formatting
* [stripe] add thought signature docs
* [stripe] remove unused import
* add AWS fields for KeyManagementSettings
* docs IAM roles
* use aws iam auth on secret manager v2
* fix: load_aws_secret_manager
* test_secret_manager_with_iam_role_settings
* Add thought signature support to v1/messages api
* update the thinking level handling logic
* update the thinking level handling logic
* Add streaming support
* fix intalling litellm error
Gemini 3 models require 'includeThoughts: True' in the thinkingConfig to return the actual thought text. Previously, using reasoning_effort set the 'thinkingLevel' but missed the boolean flag, resulting in empty reasoning_content.
This fix:
1. Updates `_map_reasoning_effort_to_thinking_level` to include `includeThoughts: True` for low/medium/high.
2. Adds unit tests to verify the config mapping.
Fixes#16805
When using Gemini models (2.5/3.0) with streaming + tools enabled,
the reasoning_content field was missing from stream chunks, even though
thinking_blocks were present in non-streaming responses.
Changes:
- Convert thinking_blocks to reasoning_content for streaming responses
- Extract "thinking" field from each thinking_block
- Concatenate multiple thinking parts with newlines
- Assign to reasoning_content in chat_completion_message for streaming
Testing:
- Added test_streaming_chunk_with_tool_calls_includes_reasoning_content
- Test verifies reasoning_content appears with tool calls in streaming
- All 39 existing Gemini tests pass
- Fix blank function name in completions response when using native function calling
- Fix Enum name being used instead of Enum value for comparison in chunk conversion
- Added additional tests to cover changes
Thanks to @mcowger for the invaluable assitance with figuring this issue out!
Fixed#16863
* Use auth key name if there are no app id in in headers or in extra_data
* use key alias instead of key name
* Fix
* last priority key alias
* Fix
* Add tests
- Implement GithubCopilotResponsesAPIConfig for /responses endpoint
- Add support for models requiring responses API (e.g., gpt-5.1-codex)
- Auto-detect vision requests and set X-Initiator header
- Follow OpenAI Responses API compatibility pattern
- Add comprehensive unit tests (16 tests passing)
Fixes#16820
Fixes#16810
## Problem
When using completion() with models that have mode: "responses" (like o3-pro,
gpt-5-codex), the response_format parameter with JSON schemas was being ignored
or incorrectly handled, causing:
- Large schemas (>512 chars) to fail with "metadata.schema_dict_json: string too long" error
- Structured outputs to be silently dropped
- Users' code to break unexpectedly
## Root Cause
The completion -> responses bridge in
litellm/completion_extras/litellm_responses_transformation/transformation.py
was missing the conversion of response_format (Chat Completion format) to
text.format (Responses API format).
The inverse bridge (responses -> completion) already had this conversion
implemented in commit 29f0ed223a, but the completion -> responses direction
was incomplete.
## Solution
Added _transform_response_format_to_text_format() method that converts:
- response_format with json_schema → text.format with json_schema
- response_format with json_object → text.format with json_object
- response_format with text → text.format with text
Updated transform_request() to detect and convert response_format parameter
before sending to litellm.responses().
## Changes
- Added _transform_response_format_to_text_format() method (lines 592-647)
- Modified transform_request() to handle response_format (lines 199-203)
- Added comprehensive tests to validate the conversion
## Testing
- 5 new unit tests covering all conversion scenarios
- Real API test with OpenAI confirming large schemas (>512 chars) work
- No more metadata.schema_dict_json errors
## Impact
Users can now use completion() with models that have mode: "responses" and:
- Use large JSON schemas without hitting metadata 512 char limit
- Get proper structured outputs
- Have their existing code continue working
* fix(spend-logs): trim logged response strings
- route spend-log responses through the existing string sanitizer so oversized base64/text fields are truncated before persistence
- add unit tests covering the truncation path and the feature flag
Note: embeddings-specific truncation (numeric vectors) is still pending and will be handled separately.
* remove unnecessary comment
* add: sanitization unit test for embeddings
* fix: simplify sanatization logic
I overcomplicated a simple change for lack of understanding, fixed.
Cost tracking was failing for Responses API when using custom deployment names
with base_model configuration. The issue occurred because:
- Chat Completions API stores model_info in 'metadata'
- Responses API stores model_info in 'litellm_metadata'
- Cost calculator only checked 'metadata', missing Responses API costs
Changes:
- Updated _get_base_model_from_metadata() to check both metadata locations
- Added comprehensive unit tests covering all scenarios
- Maintains backward compatibility (metadata takes precedence)
Fixes#16772
