[Feature Request] Support for Advanced Reasoning Parameters & Native Web Search Filters (e.g., GPT-5/o3 style) #3563
Description
Required prerequisites
- I have searched the Issue Tracker and Discussions that this hasn't already been reported. (+1 or comment there if it has.)
- Consider asking first in a Discussion.
Motivation
As LLM providers (specifically OpenAI) evolve their APIs, new parameters are being introduced that are critical for controlling model behavior and retrieving verifiable data.
Current wrapper implementations often sanitize or strictly define input arguments, which prevents users from leveraging bleeding-edge features such as:
Reasoning Effort: Controlling the compute budget (e.g., reasoning={"effort": "low"} in newer o1/o3 class models).
Native Web Search with Filters: Passing domain constraints directly to the model's native browser tool (e.g., allowed_domains).
Response Inclusions: Requesting specific metadata like citations or search sources via the include parameter.
Without support for these parameters in the Camel ModelClient or agent wrappers, developers cannot utilize the model's native ability to perform constrained research (e.g., searching only specific scientific documentation) or adjust reasoning costs.
Solution
I would like the Camel framework (specifically the OpenAI client adapter) to support the following API signature extensions:
Pass-through reasoning parameter: Allow the reasoning dictionary (e.g., {"effort": "low/medium/high"}) to be passed during generation.
Enhanced tools schema: Support complex tool definitions including filters for web_search types, rather than just function definitions.
Support for include: Allow requesting specific response components like web_search_call.action.sources.
Desired Usage Example:
Python
response = client.responses.create(
model="gpt-5.1", # or current equivalent like o3-mini
reasoning={"effort": "low"},
tools=[
{
"type": "web_search",
"filters": {
"allowed_domains": [
""
]
},
}
],
tool_choice="auto",
include=["web_search_call.action.sources"],
input="",
)
The internal Camel ChatAgent or ModelClient should normalize these parameters and ensure they reach the backend API provider without being stripped.
Alternatives
Custom Tool Implementation: Currently, we have to build a custom FunctionTool for web searching and manually handle the filtering logic within the tool's code. However, this bypasses the model's native understanding of search constraints and does not allow for the reasoning effort adjustments.
Raw API Calls: Bypassing Camel entirely to use the official SDK directly, which breaks the multi-agent orchestration benefits of using Camel.
Additional context
No response