Configuring Provider-Specific Thinking Settings for LLMs in TradingAgents

You can tune the reasoning depth of LLMs in TradingAgents by setting provider-specific keys—google_thinking_level, openai_reasoning_effort, or anthropic_effort—in the configuration dictionary, which the framework translates into the correct API parameters for each client.

Configuring provider-specific thinking settings for LLMs in TradingAgents allows you to balance latency against reasoning quality without hard-coding provider logic into your trading graph. The framework centralizes these options in DEFAULT_CONFIG, collects them through interactive CLI prompts, and maps them to the correct API parameters inside provider-specific client classes.

Architecture of Thinking Settings

TradingAgents decouples the user’s intent—"use high reasoning depth"—from the implementation details of each LLM provider. The data flows through four distinct layers:

Step	Action	Source File
Configuration defaults	tradingagents/default_config.py defines optional keys: google_thinking_level, openai_reasoning_effort, anthropic_effort.	[default_config.py](https://github.com/TauricResearch/TradingAgents/blob/main/tradingagents/default_config.py#L10-L18)
CLI collection	Interactive prompts ask_gemini_thinking_config(), ask_openai_reasoning_effort(), and ask_anthropic_effort() capture user choices.	[cli/utils.py](https://github.com/TauricResearch/TradingAgents/blob/main/cli/utils.py)
Config injection	cli/main.py writes the selected values into the runtime configuration dictionary.	cli/main.py#L579-L599
Provider kwargs	TradingAgentsGraph._get_provider_kwargs() extracts the generic keys and builds a provider-specific kwargs dict.	trading_graph.py#L36-L56
Client mapping	Factory create_llm_client() instantiates the correct client class, which maps the generic key to the native API parameter.	[factory.py](https://github.com/TauricResearch/TradingAgents/blob/main/tradingagents/llm_clients/factory.py)

Provider-Specific Mapping Logic

Each client class handles the translation internally:

• GoogleClient: Maps thinking_level to thinking_level for Gemini 3 models, or to thinking_budget (-1 for high, 0 for minimal) for Gemini 2.5 series.
• OpenAIClient: Passes reasoning_effort directly through the _PASSTHROUGH_KWARGS list to the underlying ChatOpenAI constructor.
• AnthropicClient: Translates the generic effort key to the provider’s native parameter.

Practical Configuration Examples

Programmatic Configuration

You can override the default thinking settings before instantiating the graph:

from tradingagents.default_config import DEFAULT_CONFIG
from tradingagents.graph.trading_graph import TradingAgentsGraph

# Configure provider-specific thinking settings

DEFAULT_CONFIG["google_thinking_level"] = "high"
DEFAULT_CONFIG["openai_reasoning_effort"] = "medium"
DEFAULT_CONFIG["anthropic_effort"] = "high"

# Instantiate the graph with the modified configuration

graph = TradingAgentsGraph(
    selected_analysts=["market", "news"],
    config=DEFAULT_CONFIG,
    debug=True,
)

The TradingAgentsGraph receives the modified config, _get_provider_kwargs() extracts the three keys, and the appropriate client receives them.

Interactive CLI Configuration

When using the interactive setup, the CLI collects thinking preferences based on the selected provider:

# In cli/main.py – after the user selects a provider:

if selected_llm_provider == "google":
    thinking_level = ask_gemini_thinking_config()   # Returns "high" or "minimal"

else:
    thinking_level = None

# Assemble the final configuration dict that the graph will read:

config = {
    "llm_provider": selected_llm_provider,
    "deep_think_llm": selected_deep_thinker,
    "quick_think_llm": selected_shallow_thinker,
    "google_thinking_level": thinking_level,
    # … other options …

}

The CLI stores the provider-specific mode under the generic key; the graph later reads it during initialization.

GoogleClient Translation Logic

The GoogleClient class adapts the generic thinking_level to the specific API parameter based on the model version:

# Inside GoogleClient.get_llm()

thinking_level = self.kwargs.get("thinking_level")
if thinking_level:
    model_lower = self.model.lower()
    if "gemini-3" in model_lower:
        # Gemini‑3 Pro does not accept “minimal”, map to “low”

        if "pro" in model_lower and thinking_level == "minimal":
            thinking_level = "low"
        llm_kwargs["thinking_level"] = thinking_level
    else:  # Gemini 2.5 series

        llm_kwargs["thinking_budget"] = -1 if thinking_level == "high" else 0

This mapping ensures that the same configuration value works across different Gemini model generations without requiring the user to know the underlying API differences.

Key Implementation Files

File	Purpose
tradingagents/default_config.py	Defines google_thinking_level, openai_reasoning_effort, anthropic_effort
cli/utils.py	Interactive prompts for collecting thinking settings
cli/main.py	Injects user selections into the runtime configuration
tradingagents/graph/trading_graph.py	_get_provider_kwargs() extracts provider-specific arguments
tradingagents/llm_clients/factory.py	Creates the appropriate client instance
tradingagents/llm_clients/google_client.py	Maps thinking_level to Gemini API parameters
tradingagents/llm_clients/openai_client.py	Passes reasoning_effort to ChatOpenAI
tradingagents/llm_clients/anthropic_client.py	Handles effort for Claude models

Summary

• Centralized configuration: Provider-specific thinking settings live in DEFAULT_CONFIG under keys like google_thinking_level, openai_reasoning_effort, and anthropic_effort.
• CLI integration: Interactive prompts in cli/utils.py collect user preferences and cli/main.py injects them into the configuration dictionary.
• Automatic translation: TradingAgentsGraph._get_provider_kwargs() extracts generic keys, and each LLM client (e.g., GoogleClient, OpenAIClient) maps them to the correct native API parameter.
• Model adaptation: The GoogleClient automatically adjusts the parameter name based on whether you are using Gemini 3 (using thinking_level) or Gemini 2.5 (using thinking_budget).

Frequently Asked Questions

How do I enable high reasoning depth for Gemini models in TradingAgents?

Set the google_thinking_level key to "high" in your configuration dictionary before creating the TradingAgentsGraph. For Gemini 2.5 models, the client automatically translates this to thinking_budget=-1; for Gemini 3 models, it passes thinking_level="high" directly to the API.

What is the difference between openai_reasoning_effort and anthropic_effort?

Both keys control the reasoning depth for their respective providers, but they target different APIs. openai_reasoning_effort is passed through to OpenAI's ChatOpenAI constructor (supporting values like "low", "medium", or "high"), while anthropic_effort is mapped to Claude's native effort parameter. The configuration layer treats them uniformly, but each client handles the provider-specific translation.

Can I mix different thinking levels for quick-thinking and deep-thinking LLMs?

Yes. The configuration dictionary supports separate entries for different providers, and you can instantiate different LLM clients with different settings. For example, you might configure google_thinking_level="minimal" for a quick-thinking Flash model used in SignalProcessor, while using openai_reasoning_effort="high" for a deep-thinking o1 model used in Reflector. The TradingAgentsGraph initializes each LLM independently based on the provider-specific kwargs extracted from the config.

Where does the translation from generic keys to API parameters happen?

The translation occurs in the provider-specific client classes within tradingagents/llm_clients/. GoogleClient (in google_client.py) maps thinking_level to either thinking_level or thinking_budget depending on the model version. OpenAIClient (in openai_client.py) passes reasoning_effort through its _PASSTHROUGH_KWARGS list. AnthropicClient handles the effort key similarly. The TradingAgentsGraph._get_provider_kwargs() method (in trading_graph.py) is responsible for extracting the generic keys from the config and routing them to the appropriate client.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}