Skip to content

Conversation

@yyhhyyyyyy
Copy link
Collaborator

@yyhhyyyyyy yyhhyyyyyy commented Oct 12, 2025

support gemini upstream Provider DB

Summary by CodeRabbit

  • New Features
    • Enhanced Gemini support: dynamic model discovery, normalized model IDs, and proper image-generation handling/streaming.
    • Automatic classification of image-generation vs. chat models and more accurate capability detection (vision, tool use, image output).
  • Improvements
    • Standardized model catalog: cleaned modalities, limits, costs, and naming for clarity and consistency.
    • Unsupported or deprecated models are hidden or clearly marked.
    • Models no longer auto-enable; enable them manually as needed.
  • UI
    • Settings: Gemini thinking budget accepts -1 without validation errors.
  • Deprecations
    • Some models and tool-calling capabilities disabled or removed.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 12, 2025

Walkthrough

Provider DB is pruned and standardized (modalities, limits, costs, support flags). Config layer now resolves provider aliases and model IDs (including Google/Gemini normalization) and exposes capability checks. Renderer model type reflects image-output capability. Gemini provider refactors to use DB-backed model mapping, normalized IDs, capability-driven config, and updated response parsing. UI tweaks thinkingBudget validation for Gemini.

Changes

Cohort / File(s) Summary
Provider DB standardization
resources/model-db/providers.json
Prunes/marks unsupported models, standardizes modalities to mostly text-only, adjusts limits/costs, adds explicit support/tool flags, renames display names, and refines active listings per provider.
Config presenter lookup/type
src/main/presenter/configPresenter/index.ts
Resolves provider IDs via modelCapabilities.resolveProviderId(...) before DB access; sets renderer model type to ImageGeneration when output modalities include image; otherwise Chat.
Model capabilities API
src/main/presenter/configPresenter/modelCapabilities.ts
Makes resolveProviderId public; adds supportsVision, supportsToolCall, supportsImageOutput; extends provider aliases (dashscopealibaba-cn, geminigoogle).
Model config normalization
src/main/presenter/configPresenter/modelConfig.ts
Adds geminigoogle alias; normalizes model IDs by lowercasing and stripping leading models/ for lookups.
Gemini provider refactor
src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
Switches to DB-backed fallback model mapping; normalizes model IDs with models/ prefix; derives capabilities (vision/tool/reasoning/image-gen) via modelCapabilities; updates generation/streaming, tools config, thinking-budget handling, safety mapping, response parsing (legacy/new thinking); stops auto-enabling models.
Settings UI tweak
src/renderer/src/components/settings/ModelConfigDialog.vue
Adds Gemini provider check; relaxes genericThinkingBudgetError when provider is Gemini and value is -1.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor User
  participant UI as Settings UI
  participant CP as Config Presenter
  participant MC as ModelCapabilities
  participant DB as Provider DB
  participant GP as Gemini Provider
  participant Google as Google API

  User->>UI: Select provider/model
  UI->>CP: getDbProviderModels(providerId)
  CP->>MC: resolveProviderId(providerId)
  MC-->>CP: normalizedProviderId
  CP->>DB: read providers[normalizedProviderId]
  DB-->>CP: provider models
  CP->>MC: supportsImageOutput(providerId, modelId)?
  MC-->>CP: true/false
  CP-->>UI: models with type Chat/ImageGeneration

  User->>GP: Generate (modelId)
  GP->>GP: ensureGoogleModelName(models/... prefix)
  GP->>MC: supportsToolCall/vision/imageOutput(model)
  MC-->>GP: capability flags
  alt No models from API
    GP->>DB: fallback to provider DB models
  end
  GP->>Google: generateContent(stream?) with normalized model + config
  Google-->>GP: candidates/stream (incl. thinking/content)
  GP->>GP: parse thinking (legacy/new), tools results
  GP-->>User: response/content (images/text/errors)
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

Suggested reviewers

  • zerob13

Poem

I hop through configs, ears tuned to the flow,
Prune the gardens of models, neat rows in a row.
Gemini’s stars aligned with models/ in name,
Capabilities checked—a tidy new game.
With budgets that think and images that gleam,
I thump in approval: a well-synced stream. 🐇✨

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 clearly summarizes the primary feature added by this pull request, namely integrating upstream Provider DB support for the Gemini model, and aligns with the changes across provider configurations and presenter logic without unnecessary detail. It is concise, specific, and immediately conveys the main intent to reviewers.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/gemini-providerdb-integration

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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
src/renderer/src/components/settings/ModelConfigDialog.vue (2)

597-597: Consider using capability-based checks instead of hard-coded provider ID.

The hard-coded check props.providerId?.toLowerCase() === 'gemini' may not align with provider alias resolution (e.g., geminigoogle mapping in modelConfig.ts). If the resolved provider ID is google rather than gemini, this check would fail.

Consider querying a capability flag or checking the resolved provider ID:

-const isGeminiProvider = computed(() => props.providerId?.toLowerCase() === 'gemini')
+const isGeminiProvider = computed(() => {
+  const resolvedId = props.providerId?.toLowerCase()
+  return resolvedId === 'gemini' || resolvedId === 'google'
+})

Or better yet, expose a capability check from configPresenter such as supportsUnboundedThinkingBudget(providerId, modelId) for clearer semantics.


671-673: Add clarifying comment for Gemini’s unbounded thinkingBudget

In ModelConfigDialog.vue, annotate the -1 special case:

 if (!range) return ''
+// Gemini supports –1 as an unbounded (dynamic) thinking budget
 if (isGeminiProvider.value && value === -1) {
   return ''
 }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4532aa3 and 667424b.

📒 Files selected for processing (6)
  • resources/model-db/providers.json (18 hunks)
  • src/main/presenter/configPresenter/index.ts (2 hunks)
  • src/main/presenter/configPresenter/modelCapabilities.ts (3 hunks)
  • src/main/presenter/configPresenter/modelConfig.ts (2 hunks)
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts (15 hunks)
  • src/renderer/src/components/settings/ModelConfigDialog.vue (2 hunks)
🧰 Additional context used
📓 Path-based instructions (24)
src/renderer/src/**/*

📄 CodeRabbit inference engine (.cursor/rules/i18n.mdc)

src/renderer/src/**/*: All user-facing strings must use i18n keys (avoid hardcoded user-visible text in code)
Use the 'vue-i18n' framework for all internationalization in the renderer
Ensure all user-visible text in the renderer uses the translation system

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/**/*.{vue,ts,js,tsx,jsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

渲染进程代码放在 src/renderer

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/**/*.{vue,ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/vue-best-practices.mdc)

src/renderer/src/**/*.{vue,ts,tsx,js,jsx}: Use the Composition API for better code organization and reusability
Implement proper state management with Pinia
Utilize Vue Router for navigation and route management
Leverage Vue's built-in reactivity system for efficient data handling

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/**/*.vue

📄 CodeRabbit inference engine (.cursor/rules/vue-best-practices.mdc)

Use scoped styles to prevent CSS conflicts between components

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/**/*.{ts,tsx,vue}

📄 CodeRabbit inference engine (.cursor/rules/vue-shadcn.mdc)

src/renderer/**/*.{ts,tsx,vue}: Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
Use TypeScript for all code; prefer types over interfaces.
Avoid enums; use const objects instead.
Use arrow functions for methods and computed properties.
Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/**/*.{vue,ts}

📄 CodeRabbit inference engine (.cursor/rules/vue-shadcn.mdc)

Implement lazy loading for routes and components.

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/**/*.{ts,vue}

📄 CodeRabbit inference engine (.cursor/rules/vue-shadcn.mdc)

src/renderer/**/*.{ts,vue}: Use useFetch and useAsyncData for data fetching.
Implement SEO best practices using Nuxt's useHead and useSeoMeta.

Use Pinia for frontend state management (do not introduce alternative state libraries)

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
**/*.{ts,tsx,js,vue}

📄 CodeRabbit inference engine (CLAUDE.md)

Use English for all logs and comments

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
**/*.{ts,tsx,vue}

📄 CodeRabbit inference engine (CLAUDE.md)

Enable and adhere to strict TypeScript typing (avoid implicit any, prefer precise types)

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/renderer/{src,shell,floating}/**/*.vue

📄 CodeRabbit inference engine (CLAUDE.md)

src/renderer/{src,shell,floating}/**/*.vue: Use Vue 3 Composition API for all components
All user-facing strings must use i18n keys via vue-i18n (no hard-coded UI strings)
Use Tailwind CSS utilities and ensure styles are scoped in Vue components

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/components/**/*

📄 CodeRabbit inference engine (CLAUDE.md)

Organize UI components by feature within src/renderer/src/

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/**

📄 CodeRabbit inference engine (AGENTS.md)

Put application code for the Vue app under src/renderer/src (components, stores, views, i18n, lib)

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/**/*.{vue,ts}

📄 CodeRabbit inference engine (AGENTS.md)

All user-facing strings in the renderer must use vue-i18n keys defined in src/renderer/src/i18n

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
**/*.{js,jsx,ts,tsx,vue}

📄 CodeRabbit inference engine (AGENTS.md)

Apply Prettier formatting: single quotes, no semicolons, max width 100

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/renderer/**/*.vue

📄 CodeRabbit inference engine (AGENTS.md)

Name Vue components in PascalCase (e.g., ChatInput.vue)

Files:

  • src/renderer/src/components/settings/ModelConfigDialog.vue
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/development-setup.mdc)

**/*.{js,jsx,ts,tsx}: 使用 OxLint 进行代码检查
Log和注释使用英文书写

**/*.{js,jsx,ts,tsx}: Use OxLint for JS/TS code; pre-commit hooks run lint-staged and typecheck
Use camelCase for variables and functions
Use PascalCase for types and classes
Use SCREAMING_SNAKE_CASE for constants

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/{main,renderer}/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/electron-best-practices.mdc)

src/{main,renderer}/**/*.ts: Use context isolation for improved security
Implement proper inter-process communication (IPC) patterns
Optimize application startup time with lazy loading
Implement proper error handling and logging for debugging

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/main/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/electron-best-practices.mdc)

Use Electron's built-in APIs for file system and native dialogs

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/error-logging.mdc)

**/*.{ts,tsx}: 始终使用 try-catch 处理可能的错误
提供有意义的错误信息
记录详细的错误日志
优雅降级处理
日志应包含时间戳、日志级别、错误代码、错误描述、堆栈跟踪(如适用)、相关上下文信息
日志级别应包括 ERROR、WARN、INFO、DEBUG
不要吞掉错误
提供用户友好的错误信息
实现错误重试机制
避免记录敏感信息
使用结构化日志
设置适当的日志级别

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/main/**/*.{ts,js,tsx,jsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

主进程代码放在 src/main

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/main/**

📄 CodeRabbit inference engine (AGENTS.md)

Place all Electron main-process code under src/main/

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
src/main/presenter/**

📄 CodeRabbit inference engine (AGENTS.md)

src/main/presenter/**: Organize main-process presenters under src/main/presenter/ (Window/Tab/Thread/Mcp/Config/LLMProvider)
Follow the Presenter pattern for main-process modules

Files:

  • src/main/presenter/configPresenter/modelConfig.ts
  • src/main/presenter/configPresenter/index.ts
  • src/main/presenter/configPresenter/modelCapabilities.ts
  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
{build,resources,out,dist}/**

📄 CodeRabbit inference engine (AGENTS.md)

Keep build outputs and assets within build/, resources/, out/, and dist/

Files:

  • resources/model-db/providers.json
src/main/presenter/llmProviderPresenter/providers/*.ts

📄 CodeRabbit inference engine (.cursor/rules/llm-agent-loop.mdc)

src/main/presenter/llmProviderPresenter/providers/*.ts: Each file in src/main/presenter/llmProviderPresenter/providers/*.ts should handle interaction with a specific LLM API, including request/response formatting, tool definition conversion, native/non-native tool call management, and standardizing output streams to a common event format.
Provider implementations must use a coreStream method that yields standardized stream events to decouple the main loop from provider-specific details.
The coreStream method in each Provider must perform a single streaming API request per conversation round and must not contain multi-round tool call loop logic.
Provider files should implement helper methods such as formatMessages, convertToProviderTools, parseFunctionCalls, and prepareFunctionCallPrompt as needed for provider-specific logic.
All provider implementations must parse provider-specific data chunks and yield standardized events for text, reasoning, tool calls, usage, errors, stop reasons, and image data.
When a provider does not support native function calling, it must prepare messages using prompt wrapping (e.g., prepareFunctionCallPrompt) before making the API call.
When a provider supports native function calling, MCP tools must be converted to the provider's format (e.g., using convertToProviderTools) and included in the API request.
Provider implementations should aggregate and yield usage events as part of the standardized stream.
Provider implementations should yield image data events in the standardized format when applicable.
Provider implementations should yield reasoning events in the standardized format when applicable.
Provider implementations should yield tool call events (tool_call_start, tool_call_chunk, tool_call_end) in the standardized format.
Provider implementations should yield stop events with appropriate stop_reason in the standardized format.
Provider implementations should yield error events in the standardized format...

Files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
🧠 Learnings (8)
📚 Learning: 2025-07-21T01:46:52.880Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/llm-agent-loop.mdc:0-0
Timestamp: 2025-07-21T01:46:52.880Z
Learning: Applies to src/main/presenter/llmProviderPresenter/streamEvents.ts : Standardized stream events should conform to the `LLMCoreStreamEvent` interface, ideally defined in a shared file such as `src/main/presenter/llmProviderPresenter/streamEvents.ts`.

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-09-06T03:07:23.817Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-06T03:07:23.817Z
Learning: Applies to src/main/presenter/llmProviderPresenter/providers/*.ts : Each LLM provider implementation must expose a coreStream method following the standardized event interface

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-07-21T01:46:52.880Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/llm-agent-loop.mdc:0-0
Timestamp: 2025-07-21T01:46:52.880Z
Learning: Applies to src/main/presenter/llmProviderPresenter/providers/*.ts : Provider implementations must use a `coreStream` method that yields standardized stream events to decouple the main loop from provider-specific details.

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-07-21T01:46:52.880Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/llm-agent-loop.mdc:0-0
Timestamp: 2025-07-21T01:46:52.880Z
Learning: Applies to src/main/presenter/llmProviderPresenter/index.ts : `src/main/presenter/llmProviderPresenter/index.ts` should manage the overall Agent loop, conversation history, tool execution via `McpPresenter`, and frontend communication via `eventBus`.

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-07-21T01:46:52.880Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/llm-agent-loop.mdc:0-0
Timestamp: 2025-07-21T01:46:52.880Z
Learning: Applies to src/main/presenter/llmProviderPresenter/index.ts : The main Agent loop should send standardized `STREAM_EVENTS` (`RESPONSE`, `END`, `ERROR`) to the frontend via `eventBus`.

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-07-21T01:46:52.880Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/llm-agent-loop.mdc:0-0
Timestamp: 2025-07-21T01:46:52.880Z
Learning: Applies to src/main/presenter/llmProviderPresenter/providers/*.ts : Provider implementations should aggregate and yield usage events as part of the standardized stream.

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-09-04T11:03:30.184Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/provider-guidelines.mdc:0-0
Timestamp: 2025-09-04T11:03:30.184Z
Learning: Integrate via the llmProviderPresenter entry point (src/main/presenter/llmProviderPresenter/index.ts) as the related implementation entry

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
📚 Learning: 2025-07-21T01:46:52.880Z
Learnt from: CR
PR: ThinkInAIXYZ/deepchat#0
File: .cursor/rules/llm-agent-loop.mdc:0-0
Timestamp: 2025-07-21T01:46:52.880Z
Learning: Applies to src/main/presenter/llmProviderPresenter/providers/*.ts : Each file in `src/main/presenter/llmProviderPresenter/providers/*.ts` should handle interaction with a specific LLM API, including request/response formatting, tool definition conversion, native/non-native tool call management, and standardizing output streams to a common event format.

Applied to files:

  • src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts
🧬 Code graph analysis (2)
src/main/presenter/configPresenter/index.ts (1)
src/main/presenter/configPresenter/modelCapabilities.ts (1)
  • modelCapabilities (123-123)
src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts (2)
src/shared/types/presenters/llmprovider.presenter.d.ts (1)
  • MODEL_META (27-42)
src/main/presenter/configPresenter/modelCapabilities.ts (1)
  • modelCapabilities (123-123)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: build-check (x64)
🔇 Additional comments (12)
src/main/presenter/configPresenter/index.ts (2)

665-667: LGTM! Provider ID resolution correctly uses alias mapping.

The code properly resolves provider aliases (e.g., geminigoogle) using modelCapabilities.resolveProviderId with a safe fallback to the lowercased original ID. This ensures consistent provider lookup in the DB.


683-686: LGTM! Capability-driven model type determination.

The conditional type assignment based on modalities.output correctly identifies image generation models. This aligns with the broader PR goal of standardizing model capabilities via the Provider DB.

src/main/presenter/configPresenter/modelConfig.ts (2)

24-25: LGTM! Gemini provider alias is consistent across the codebase.

The gemini: 'google' alias addition matches the pattern in modelCapabilities.ts (lines 21-22) and supports unified provider resolution throughout the application.


242-244: LGTM! Model ID normalization handles Google Gemini SDK format.

The code correctly strips the models/ prefix that Google Gemini SDK returns, enabling consistent model ID lookups. The inline comment clearly explains the purpose.

src/main/presenter/configPresenter/modelCapabilities.ts (2)

61-65: LGTM! Making resolveProviderId public enables centralized alias resolution.

The method is now used by configPresenter/index.ts (line 666) to resolve provider aliases when accessing the Provider DB. This centralizes alias handling logic and prevents duplication.


103-120: LGTM! New capability methods follow consistent patterns.

The three new methods (supportsVision, supportsToolCall, supportsImageOutput) enable capability-driven model configuration. They follow the same pattern as existing methods and correctly query the Provider DB model definitions.

src/main/presenter/llmProviderPresenter/providers/geminiProvider.ts (6)

70-72: LGTM! Centralized model name normalization for Google API.

The ensureGoogleModelName helper consistently prefixes model IDs with models/ as required by the Google Gemini SDK. This prevents errors from missing prefixes and centralizes the normalization logic.


88-101: LGTM! Provider DB fallback ensures robustness.

The fallback to getDbProviderModels when the Gemini API returns no models is a good defensive measure. The mapping correctly populates MODEL_META fields from the Provider DB configuration, maintaining functionality even when the API is unavailable.


105-148: LGTM! Capability-driven model mapping improves maintainability.

The refactored model mapping queries modelCapabilities for each capability (vision, tool call, reasoning, image output) rather than hard-coding assumptions. This makes the code data-driven and easier to maintain as the Provider DB evolves.

Minor observation: The group categorization logic (lines 132-133) uses regex patterns that could be fragile if Gemini changes naming conventions. Consider whether group information should also come from the Provider DB.


312-318: LGTM! Thinking budget support check is capability-driven.

The supportsThinkingBudget method correctly queries modelCapabilities.getThinkingBudgetRange to determine support, replacing hard-coded model name checks. This aligns with the broader refactor toward capability-driven configuration.


848-858: LGTM! Conditional function calling configuration prevents empty tool config.

The guard clause checking hasFunctionDeclarations before configuring functionCallingConfig is a good defensive measure. It prevents sending tool configuration to the Gemini API when there are no actual function declarations, avoiding potential API errors or unexpected behavior.


250-274: Verify the intentional removal of automatic model enablement.

The updated autoEnableModelsIfNeeded method no longer automatically enables models for Gemini, requiring users to manually enable them. This is a breaking behavioral change that could impact user experience, especially for new installations.

Please confirm:

  1. This behavioral change is intentional and aligns with product requirements
  2. There is user-facing documentation or UI guidance explaining that users need to manually enable Gemini models
  3. The console log message (line 272) provides sufficient guidance

Consider whether there should be a notification or toast in the UI directing users to enable models, rather than just a console message they may not see.

Comment on lines +12594 to +12603
"default": true,
"budget": {
"default": -1,
"min": 0,
"max": 24576
}
},
"search": {
"supported": true,
"default": false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Fix reasoning budget defaults to satisfy validation bounds

reasoning.budget.default is -1 while min is 0, so the default is outside the declared range. The UI layer now validates thinkingBudget against these bounds, and this mismatch causes the Gemini config to be rejected/flagged immediately. The same issue appears in the other Gemini 2.5 entries where default is -1 and min is 0/128/512. Please align the defaults with the declared minimums (or relax the minimum) before landing. Example fix:

-            "default": -1,
-            "min": 0,
+            "default": 0,
+            "min": 0,
             "max": 24576

(Be sure to adjust the corresponding budget blocks for the other Gemini 2.5 variants as well.)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
"default": true,
"budget": {
"default": -1,
"min": 0,
"max": 24576
}
},
"search": {
"supported": true,
"default": false
"default": true,
"budget": {
"default": 0,
"min": 0,
"max": 24576
}
},
"search": {
"supported": true,
"default": false
🤖 Prompt for AI Agents
In resources/model-db/providers.json around lines 12594 to 12603, the
reasoning.budget.default is set to -1 while the declared min is 0 (making the
default invalid); update reasoning.budget.default to be at least the declared
min (e.g., set to 0 or the appropriate min for Gemini 2.5 variants) and apply
the same change to the other Gemini 2.5 entries that currently have default -1
so all reasoning.budget.default values fall within their corresponding min..max
ranges.

@zerob13
Copy link
Collaborator

zerob13 commented Oct 12, 2025

@codex review

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

// 正确配置思考功能
if (reasoning) {
config.thinkingConfig = {
includeThoughts: true
}
// 仅对支持 thinkingBudget 的 Gemini 2.5 系列模型添加 thinkingBudget 参数
if (modelId && this.supportsThinkingBudget(modelId) && thinkingBudget !== undefined) {
config.thinkingConfig.thinkingBudget = thinkingBudget
}

P1 Badge Skip sending negative thinking budgets to Gemini API

The provider DB now ships Gemini models with a default thinking budget of -1 to signal “use the server default”, and the settings dialog allows users to keep -1 without validation errors. However getGenerateContentConfig still forwards any numeric value (including -1) in thinkingBudget whenever the model supports reasoning. The Gemini API expects a non‑negative token budget and will reject calls that include a negative number, so reasoning‑capable models will start failing as soon as the new defaults are loaded. Consider omitting the thinkingBudget field whenever the value is less than 0 instead of passing it through.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting

@zerob13 zerob13 merged commit d6ee59d into dev Oct 12, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants