feat: gemini thinking_level && snake params

[seefs001]

fix #2273 #2181

Summary by CodeRabbit

• New Features
  • Gemini thinking configuration now accepts alternative field naming conventions (snake_case in addition to existing formats) for enhanced configuration flexibility.
  • Restored and exposed the thinking level field for Gemini thinking features.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added JSON unmarshalling support to GeminiThinkingConfig to handle snake_case field names (include_thoughts, thinking_budget, thinking_level), mapping them to camelCase equivalents during deserialization. Restored and exposed the ThinkingLevel field as json.RawMessage.

Changes

Cohort / File(s)	Change Summary
JSON unmarshalling enhancement dto/gemini.go	Added ThinkingLevel field (json.RawMessage) and implemented UnmarshalJSON() method to map snake_case input fields to camelCase struct fields using an internal alias pattern.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Review focus: Verify the UnmarshalJSON implementation correctly maps all snake_case variants (include_thoughts, thinking_budget, thinking_level) to their camelCase counterparts
• Ensure the json.RawMessage type for ThinkingLevel is appropriate for the use case
• Confirm the alias struct pattern doesn't cause unintended behavior or infinite recursion

Poem

🐰 A rabbit hops through JSON fields,
Where snakes and camels reconcile,
Snake_case meets camelCase with ease,
Unmarshalling data to please! 🐪✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main changes: adding thinking_level support and snake_case parameter support to GeminiThinkingConfig.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

dto/gemini.go (1)

148-177: Add clarification about the purpose of snake_case support.

The implementation is correct. However, the web search confirms that the Gemini API itself uses camelCase (includeThoughts, thinkingBudget, thinkingLevel), not snake_case. The snake_case support in this UnmarshalJSON method is for parsing user input or other sources, not for API compatibility.

Consider enhancing the documentation to clarify this purpose:

// UnmarshalJSON allows GeminiThinkingConfig to accept both snake_case and camelCase fields
// for flexibility in parsing user input. The Gemini API itself uses camelCase.
// When both formats are present, snake_case takes precedence.
func (c *GeminiThinkingConfig) UnmarshalJSON(data []byte) error {

This clarifies that the dual-format support is a convenience feature, not a requirement for API compatibility.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between efb8f1f and 6b30f04.

📒 Files selected for processing (1)

• dto/gemini.go (1 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: 9Ninety
Repo: QuantumNous/new-api PR: 1273
File: relay/channel/gemini/relay-gemini.go:97-116
Timestamp: 2025-06-21T03:37:41.726Z
Learning: In relay/channel/gemini/relay-gemini.go, the thinking budget calculation logic (including the MaxOutputTokens multiplication) was introduced in PR #1247. PR #1273 focused specifically on decoupling the thoughts summary feature from thinking budget settings and did not modify the existing thinking budget behavior.

📚 Learning: 2025-06-21T03:37:41.726Z

Learnt from: 9Ninety
Repo: QuantumNous/new-api PR: 1273
File: relay/channel/gemini/relay-gemini.go:97-116
Timestamp: 2025-06-21T03:37:41.726Z
Learning: In relay/channel/gemini/relay-gemini.go, the thinking budget calculation logic (including the MaxOutputTokens multiplication) was introduced in PR #1247. PR #1273 focused specifically on decoupling the thoughts summary feature from thinking budget settings and did not modify the existing thinking budget behavior.

Applied to files:

• dto/gemini.go

🧬 Code graph analysis (1)

dto/gemini.go (1)

common/json.go (1)

• Unmarshal (9-11)

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

Clarify or resolve the TODO comment.

The TODO comment mentions a "conflict with thinkingbudget" but doesn't explain what the conflict is or how it should be resolved. Since you're exposing the ThinkingLevel field in this PR, please clarify:

• What is the nature of the conflict?
• Are both fields meant to coexist?
• Should this TODO be addressed before merging?

Can you provide more context about this conflict and whether it impacts the functionality?

---

---

🏁 Script executed:

```shell
#!/bin/bash
# Examine the file structure and context around the TODO comment
echo "=== Lines 140-180 of dto/gemini.go ==="
sed -n '140,180p' dto/gemini.go

echo -e "\n=== Search for 'Thinking' field references ==="
rg -n -i 'thinking' dto/gemini.go | head -20

Length of output: 2231

---

🏁 Script executed:

#!/bin/bash
# Search for ThinkingBudget field definition
echo "=== All 'ThinkingBudget' occurrences ==="
rg -n 'ThinkingBudget' dto/gemini.go

echo -e "\n=== All 'thinking_budget' occurrences ==="
rg -n 'thinking_budget' dto/gemini.go

Length of output: 488

---

🏁 Script executed:

#!/bin/bash
# Check the GeminiThinkingConfig struct definition
echo "=== GeminiThinkingConfig struct ==="
ast-grep --pattern 'type GeminiThinkingConfig struct { $$$ }'

Length of output: 396

---

🏁 Script executed:

#!/bin/bash
# Search for TODO comments in the file to understand context
echo "=== All TODO comments in dto/gemini.go ==="
rg -n 'TODO' dto/gemini.go

Length of output: 85

---

Clarify the TODO comment on line 144.

The TODO "Conflict with thinkingbudget" is vague and creates ambiguity about whether ThinkingLevel is safe to use. The UnmarshalJSON method shows both fields are intentionally supported, but the comment doesn't explain:

• What the conflict is
• Whether it's already resolved
• Any limitations or considerations for this field

Either resolve the conflict or replace the TODO with a clear comment explaining the design decision and how both fields coexist.

🤖 Prompt for AI Agents

In dto/gemini.go around lines 144 to 145, replace the vague TODO "Conflict with
thinkingbudget" with a clear explanatory comment stating the nature of the
conflict and the chosen design: note that UnmarshalJSON intentionally supports
both ThinkingLevel and ThinkingBudget, specify which field takes precedence when
both are present (or that this is undefined), document any compatibility or
migration behavior (e.g., ThinkingBudget is preferred/legacy, ThinkingLevel
added for new API), and list any limitations (format differences, validation
rules, or future deprecation plans). Update the comment to explain how callers
should set these fields and remove the TODO so future readers understand the
resolved behavior and constraints.