[BUG] Gemini 3 Pro on OpenRouter: No thinking_level parameter (thinking budget not supported)

[DoS007]

Environment

Self-deployed from GitHub

Description

The thinkingLevel parameter, recommended for Gemini 3 models and onwards, lets you control reasoning behavior. You can set thinking level to "low" or "high". If you don't specify a thinking level, Gemini will use the model's default dynamic thinking level, "high", for Gemini 3 Pro Preview. [...] You cannot disable thinking for Gemini 3 Pro. Gemini 2.5 series models don't support thinkingLevel; use thinkingBudget instead.

https://ai.google.dev/gemini-api/docs/thinking

Device and browser

not relevant

Screenshots and more

No response

Willingness to Contribute

• 🙋‍♂️ Yes, I would like to contribute a fix.

[github-actions]

Thank you for reporting this issue!

Analysis

I've investigated the problem with Gemini 3 Pro on OpenRouter and the thinking_level parameter. Here's what I found:

The Issue

You're correct that Gemini 3 models introduced a new thinking_level parameter that replaces thinking_budget for controlling reasoning behavior. According to Google's documentation, Gemini 3 Pro supports:

• thinking_level: "low" or "high" (with "medium" planned)
• Dynamic thinking level as default when unspecified

However, OpenRouter does not support these native Gemini parameters.

OpenRouter's Implementation

After checking OpenRouter's API documentation, they use their own simplified parameter:

• reasoning: boolean (true/false) to enable/disable reasoning
• include_reasoning: boolean to include reasoning details in the response

OpenRouter does not expose the native Gemini thinking_level or thinking_budget parameters.

The Fix

Big-AGI was incorrectly adding a llmVndGeminiThinkingBudget parameter for Google models on OpenRouter (line 154-155 in openrouter.models.ts), which doesn't work because:

1. OpenRouter doesn't support the native Gemini thinking parameters
2. OpenRouter uses its own reasoning boolean instead
3. This was causing confusion and non-functional UI controls

I've removed this incorrect parameter mapping. The reasoning capability is still correctly detected and enabled via the LLM_IF_OAI_Reasoning interface, which is set based on OpenRouter's supported_parameters array.

For Users

When using Gemini 3 Pro (or any reasoning-capable model) on OpenRouter:

• ✅ Reasoning is automatically enabled when the model supports it
• ✅ Big-AGI correctly detects the reasoning interface
• ❌ You cannot control the thinking level/budget (OpenRouter limitation)
• ℹ️ OpenRouter handles reasoning with its own simplified boolean parameter

Recommendation

If you need fine-grained control over Gemini 3's thinking parameters (thinking_level), you should:

1. Use Gemini directly via Google AI Studio or Vertex AI vendor in Big-AGI
2. There you'll have access to the native llmVndGeminiThinkingLevel parameter

Hope this clarifies the situation! The fix ensures Big-AGI no longer shows non-functional thinking controls for OpenRouter's Gemini models.

---

Sources:

• Gemini API Thinking Documentation
• OpenRouter Gemini 3 Pro API Documentation

[DoS007]

Hmm. And there is no forwarding functionality on openrouter for parameters?

Maybe it's too early. Gemini 3 Pro (Preview) hasn't even introduced the medium thinking_level yet (low and high) - medium is planned (possibly searching) ai said.

But as soon, as it's available, it would be nice to have it implemented. Because with "high" there might be too much thinking tokens (and potentially more latency and cost).

[enricoros]

@DoS007 correct. For the native Gemini protocol I've implemented high medium and low (medium is not supported yet, but the API doesn't reject it, showing that support will be coming). Need the pass through via OpenRouter.

[DoS007]

@enricoros There is a solution. Gemini's thinking_level can be configured for openrouter using reasoning effort parameter. See https://openrouter.ai/docs/guides/best-practices/reasoning-tokens . The settings used for gemini 3 pro (which currently supports high and low, later maybe medium and/or minimal) can be set using that.

[enricoros]

Thanks @DoS007 - I've added the max_tokens configuration to Gemini models through OpenRouter as per the document you linked. Tested and works well, except that for Gemini 3 Pro reasoning cannot be 0 (disabled), as expected.

[DoS007]

@enricoros For controlling the reasoning on gemini (this issue), the effort parameter is more imortant than the max_tokens to configure the reasoning? https://ai.google.dev/gemini-api/docs/thinking#thinking-levels . It seems to be that openrouter's general reasoning's "effort" is for gemini directly translated to the "thinkingLevel" in the link.

(Somewhat Off topic: openrouter's generic reasoning handling and autotranslating to ai suppliers terms is one advantage, but another advantage is that unnecessary ai supplier parameter renaming, here e.g. from snake_case to camelCase, don't need to be adressed - hopefully openrouter stays with their naming for longer than google).

Edit: I see, why we may have missunderstood each other. While the doc says otherwise (outdated), the "reasoning effort level" should work with openrouter's gemini 3. If not, tell me.

[enricoros]

@DoS007 Double checking:

• right now the thinking tokens for Gemini 3 Pro on OpenRouter works as expected
• do you suggest having Also an effort adjustment for the Gemini 3 Pro models, or to Only have the effort adjustment (and remove the thinking tokens adjustment, which works now)

[DoS007]

@enricoros OpenRouter redirects to google. So it's completely dependent on google's part, what's optimal to use. And google writes: Google allows two configuration points for controlling reasoning: Thinking levels (e.g. high or low) and thinking budget (specific number of reasoning tokens to aim for).

Google says on linked page:

Note: Use the thinkingLevel parameter with Gemini 3 models. While thinkingBudget is accepted for backwards compatibility, using it with Gemini 3 Pro may result in suboptimal performance.

Now on OpenRouters part: They have a central parameter configuration that can be used for many ai suppliers and "independent" of the ai supplier's naming. They also support a mode (like high, low) which they call effort and thinking tokens (specific thinking tokens to aim for or max), which they call max_tokens.

Knowing that openrouter's parameters are directly translated to the specific ai suppliers naming (thinkingLevel and thinkingBudget currently in gemini's case), you can handle it the same, like you handle it with google directly itself (without openrouter).

My opinion:
As the policy-like reasoning (high, low) configuration is central for gemini 3, it's "mandatory" to support that on openrouter (the "effort"). So the only question is: Should "max_tokens"/thinking tokens configuration should also be made available? I'd say yes, because there might be cases where it is interesting. Like google writes:

However, if you have specific latency constraints or require the model to engage in deeper reasoning than usual, you can optionally use parameters to control thinking behavior.

So, I'd suggest having the effort adjustment and as a bonus the max_tokens/thinking tokens adjustment. I don't know what google does if both parameters are used together. Most freedom would be "off" for not sending the parameters (both) and additionally (high, low and already minimal, medium) for effort and additionally -1 and a sliding token chooser (like you probably have now) for the thinking tokens (max_tokens). With default being max_tokens/thinking tokens parameter off and reasoning effort being high. After you implemented both parameters, I could sync and test that and give you feedback what using both does.

[DoS007]

@enricoros tl;dr:

do you suggest having Also an effort adjustment for the Gemini 3 Pro models, or to Only have the effort adjustment (and remove the thinking tokens adjustment, which works now)

effort adjustment allowing: off, high, low (and maybe already minimal, medium)
thinking tokens adjustment: off, -1, and sliding selector