Python: feat: add thinking_level support for Gemini in Python#13959
Python: feat: add thinking_level support for Gemini in Python#13959markmcd wants to merge 4 commits intomicrosoft:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds support for configuring Gemini “thinking level” in the Python Google AI connector by introducing a thinking_level execution setting and mapping it to the GenAI SDK’s expected thinking_config request shape.
Changes:
- Added
thinking_leveltoGoogleAIPromptExecutionSettings. - Overrode
prepare_settings_dict()to mapthinking_level→thinking_config.thinking_level. - Added unit tests covering the new field and the mapping behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| python/semantic_kernel/connectors/ai/google/google_ai/google_ai_prompt_execution_settings.py | Adds thinking_level setting and maps it into thinking_config for requests. |
| python/tests/unit/connectors/ai/google/google_ai/test_google_ai_request_settings.py | Adds unit tests for thinking_level storage and mapping into the request dict. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| temperature: Annotated[float | None, Field(ge=0.0, le=2.0)] = None | ||
| top_p: float | None = None | ||
| top_k: int | None = None | ||
| thinking_level: Literal["minimal", "low", "medium", "high"] | str | None = None |
There was a problem hiding this comment.
Personally I prefer the | str option for forward-compatibility, while still enabling completions from the Literal, but happy to defer to maintainer style on this one.
There was a problem hiding this comment.
Automated Code Review
Reviewers: 4 | Confidence: 81%
✓ Correctness
The PR correctly adds thinking_level support for Google AI by defining the field on the base settings class and overriding prepare_settings_dict to remap it into the thinking_config structure expected by the Google GenAI SDK. The implementation is consistent with how other config fields (like tool_config) are handled in this codebase. No correctness issues found.
✓ Security Reliability
This PR adds a
thinking_levelfield to Google AI settings and overidesprepare_settings_dictto map it into thethinking_configstructure expected by the Google SDK. The implementation is straightforward and low-risk. The value is passed as a structured parameter to the SDK (not interpolated into strings), so there's no injection risk. The| strin the type annotation disables Pydantic's Literal validation but appears intentional for forward-compatibility with future API levels. No resource leaks, unsafe deserialization, secrets, or unhandled failure modes are introduced.
✓ Test Coverage
The PR adds two unit tests that cover setting thinking_level and verifying the prepare_settings_dict mapping. While these cover the happy path, there are minor gaps: no test for the None/default case in prepare_settings_dict (ensuring thinking_config is absent), and no update to the existing default settings test to verify thinking_level defaults to None. The existing test_create_options implicitly exercises the None path through inheritance but doesn't explicitly assert thinking_config absence.
✓ Design Approach
I did not find a design-level issue that meets the evidence bar. The change introduces
thinking_levelon the Google AI prompt settings and remaps it intothinking_configat request-construction time, which is consistent with how the Google AI text/chat services consumeprepare_settings_dict()before buildingGenerateContentConfigDict.
Automated review by markmcd's agents
Motivation and Context
Allow users to exercise control over how much they are willing to spend in terms of response latency and token budgets.
fixes: #13955
Description
Follows the same terminology and structure as used in the upstream API. Users provide an optional
thinking_levelparam that is plumbed through to the genai SDK.I have not added support for
thinking_budget, which takes an integer, as it's not supported by newer models and will not be supported going forward. I have not updated the Vertex code path either as that's marked as deprecated in this library.This matches the .NET implementation
Contribution Checklist