Allow `thinking_config` in `generate_content_config` for LlmAgent

[invictus2010]

Is your feature request related to a problem? Please describe. Yes.
Currently, the library strictly enforces that any thinking_config (such as the
thinking budget) must be configured via the LlmAgent.planner field
(specifically using BuiltInPlanner).

If a user attempts to set thinking_config directly within the
generate_content_config of an LlmAgent,
LlmAgent.validate_generate_content_config raises a ValueError.

This creates friction for two reasons: 1. Boilerplate: Users who simply want
to enable thinking or adjust the budget (which is effectively a model
hyperparameter) are forced to instantiate a full BuiltInPlanner object, adding
unnecessary import overhead and complexity. 2. Architectural Clarity: It
conflates "model parameters" (like temperature, max_output_tokens, and now
thinking_budget) with "agent strategy" (the Planner). Users intuitively
expect model-level settings to reside in generate_content_config.

Describe the solution you'd like I propose relaxing the validation logic in
LlmAgent to allow thinking_config to be set directly in
generate_content_config.

To prevent ambiguity or silent failures, we should implement an "Allow but Warn"
strategy:

1. Update Validation: Modify LlmAgent.validate_generate_content_config to
   remove the ValueError for thinking_config.
2. Add Precedence Warning: If both self.planner (with thinking enabled)
   AND generate_content_config.thinking_config are present, issue a
   UserWarning. This informs the user that the Planner's configuration will
   take precedence (due to the order of request processors).
3. Runtime Logging: Ideally, update BuiltInPlanner.apply_thinking_config
   to log an INFO or WARNING message if it detects it is overwriting an
   existing thinking configuration on the LlmRequest.

Describe alternatives you've considered * Status Quo: Continue enforcing
Planner usage. This maintains strict separation but keeps the developer
experience deeper than necessary for simple thinking model usage. * Silent
Overwrite: Remove the validation but add no warnings. This is risky because
the _NlPlanningRequestProcessor runs after the basic processor. A user might
set a budget of 2000 in config, have a default planner with budget 1000, and be
confused why their setting isn't working. The warning is essential.

Additional context -

Internal Logic: The underlying flow logic in
src/google/adk/flows/llm_flows/basic.py (_BasicLlmRequestProcessor) already
deep-copies the entire generate_content_config to the LlmRequest. Therefore,
once the validation in llm_agent.py is removed, the parameter will correctly
propagate to the model without further changes to the core flow.

Cross-Language Consistency: A review of the Go implementation
(google/adk-go) shows that it does not enforce this restriction. In
adk-go, ThinkingConfig is allowed within the GenerateContentConfig struct
and is passed through to the model without requiring a separate Planner
abstraction. Bringing the Python implementation in line with Go would improve
ecosystem consistency.

[Akshat8510]

Hi @invictus2010, thanks for the detailed proposal. I agree that allowing thinking_config directly in generate_content_config would greatly improve the DX and bring parity with the Go implementation.

[Akshat8510]

I've reviewed the validation logic in llm_agent.py and the flow in basic.py. I'm happy to implement the 'Allow but Warn' strategy as described, including the precedence warning and the logger update in BuiltInPlanner.

[Akshat8510]

Since this is labeled core, I wanted to check if the team is open to a community PR for this? I've recently trying contributing to the LiteLLM adapter and would love to help with this core improvement.

[invictus2010]

I do not represent the team here, but in my opinion you should go ahead, read and understand the contributing guidelines and submit a PR when ready.

…

On Sat, Jan 10, 2026, 3:50 AM Akshat8510 ***@***.***> wrote: *Akshat8510* left a comment (google/adk-python#4108) <#4108 (comment)> Since this is labeled core, I wanted to check if the team is open to a community PR for this? I've recently trying contributing to the LiteLLM adapter and would love to help with this core improvement. — Reply to this email directly, view it on GitHub <#4108 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEGXYSIXVYIYNOWSIGT5NPT4GC4MHAVCNFSM6AAAAACRGG263SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMZSGE3TGNBTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Akshat8510]

Thanks for the encouragement, @invictus2010! I’m going to start working on this right now, following the 'Allow but Warn' strategy you outlined. I’ll make sure to follow the project's contribution guidelines and should have a PR ready for review soon.

[Akshat8510]

Hi @invictus2010, just an update that I have submitted PR #4117 which implements the 'Allow but Warn' strategy we discussed.

[Akshat8510]

I’ve relaxed the validation in llm_agent.py, added the precedence UserWarning, and implemented the override logging in BuiltInPlanner. The implementation has been fully reviewed by the gemini-code-assist bot and includes comprehensive unit tests.

[Akshat8510]

Ready for the maintainers to take a look!

[wuliang229]

Thanks for the FR, I'm reviewing the PR this week.