fix: extend reasoningEffort support to all reasoning models #749
Conversation
WalkthroughAdds reasoningEffort to model settings and type; updates default model entries (o3/o4/o1 variants). Providers now set reasoning/reasoning_effort whenever configured and restrict verbosity to GPT‑5 models. ModelConfig lookup moved outside GPT‑5-only guards. UI gating for temperature now depends on supportsReasoningEffort. Changes
Sequence Diagram(s)sequenceDiagram
participant UI
participant ModelConfig
participant Provider as OpenAI* Provider
participant API as OpenAI-Compatible API
UI->>ModelConfig: Get modelId config
ModelConfig-->>UI: { reasoningEffort?, verbosity? }
UI->>Provider: openAICompletion / handleChatCompletion(request)
activate Provider
Provider->>Provider: Build requestParams
alt reasoningEffort defined
Provider->>Provider: Set reasoning / reasoning_effort
end
alt modelId startsWith "gpt-5" AND verbosity defined
Provider->>Provider: Set text.verbosity
end
Provider->>API: Send requestParams
API-->>Provider: Response/Stream
Provider-->>UI: Deliver result/stream
deactivate Provider
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (4)
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.ts (2)
34-49: Reasoning model list: deduplicate and include o4-mini-high to avoid API param errors
- 'o1-pro' appears twice.
- New model 'o4-mini-high' is a reasoning model in config, but not listed here. It means temperature won’t be removed for it, which can cause API errors on o* models that disallow temperature.
Apply:
const OPENAI_REASONING_MODELS = [ - 'o4-mini', - 'o1-pro', + 'o4-mini', + 'o4-mini-high', 'o3', 'o3-pro', 'o3-mini', 'o3-preview', 'o1-mini', - 'o1-pro', + 'o1-pro', 'o1-preview', 'o1', 'gpt-5', 'gpt-5-mini', 'gpt-5-nano', 'gpt-5-chat' ]Even better: instead of maintaining a fragile allowlist, derive “reasoning” dynamically and remove temperature when modelConfig.reasoning or modelConfig.reasoningEffort is truthy. See next comment for a concrete change.
575-579: Delete temperature for reasoning models based on modelConfig, not a hard-coded listRelying on a static prefix list is error-prone as new entries (like o4-mini-high) get added. Since you already have modelConfig here, key off that.
- // 移除推理模型的温度参数 - OPENAI_REASONING_MODELS.forEach((noTempId) => { - if (modelId.startsWith(noTempId)) delete requestParams.temperature - }) + // Remove temperature for reasoning models + if (modelConfig?.reasoning || modelConfig?.reasoningEffort) { + delete requestParams.temperature + }src/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.ts (2)
24-39: Reasoning model list: deduplicate and add o4-mini-high'o1-pro' is duplicated and 'o4-mini-high' is missing. Missing it can leave 'temperature' in requests for a reasoning model, causing request errors.
const OPENAI_REASONING_MODELS = [ - 'o4-mini', + 'o4-mini', + 'o4-mini-high', 'o1-pro', 'o3', 'o3-pro', 'o3-mini', 'o3-preview', 'o1-mini', - 'o1-pro', + 'o1-pro', 'o1-preview', 'o1', 'gpt-5', 'gpt-5-mini', 'gpt-5-nano', 'gpt-5-chat' ]
246-250: Prefer dynamic temperature removal based on modelConfig to avoid list driftYou can remove temperature for reasoning models without maintaining prefixes.
- OPENAI_REASONING_MODELS.forEach((noTempId) => { - if (modelId.startsWith(noTempId)) { - delete requestParams.temperature - } - }) + const mc = this.configPresenter.getModelConfig(modelId, this.provider.id) + if (mc?.reasoning || mc?.reasoningEffort) { + delete requestParams.temperature + }
🧹 Nitpick comments (4)
src/main/presenter/configPresenter/modelDefaultSettings.ts (1)
696-706: o4-mini-high: reasoningEffort should be 'high' to match model nameThe entry name says "High" but reasoningEffort is set to "medium". Align this to avoid misconfiguration and user confusion.
Apply:
functionCall: true, - reasoning: true, - reasoningEffort: 'medium' + reasoning: true, + reasoningEffort: 'high'src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.ts (1)
571-573: Use English-only comments per repo guidelinesReplace the Chinese comment with an English equivalent to follow “Use English for logs and comments”.
- // verbosity 仅支持 GPT-5 系列模型 + // verbosity is only supported by GPT-5 series modelssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.ts (2)
239-244: Use English-only comment for verbosity restrictionPer repo guidelines, switch the comment to English.
- // verbosity 仅支持 GPT-5 系列模型 + // verbosity is only supported by GPT-5 series models
582-587: Use English-only comment for verbosity restriction (streaming path)Same nit as above.
- // verbosity 仅支持 GPT-5 系列模型 + // verbosity is only supported by GPT-5 series models
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
src/main/presenter/configPresenter/modelDefaultSettings.ts(6 hunks)src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.ts(1 hunks)src/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{ts,tsx,js,jsx,vue}
📄 CodeRabbit Inference Engine (CLAUDE.md)
Use English for logs and comments
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.ts
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (CLAUDE.md)
Strict type checking enabled for TypeScript
**/*.{ts,tsx}: 始终使用 try-catch 处理可能的错误
提供有意义的错误信息
记录详细的错误日志
优雅降级处理
日志应包含时间戳、日志级别、错误代码、错误描述、堆栈跟踪（如适用）、相关上下文信息
日志级别应包括 ERROR、WARN、INFO、DEBUG
不要吞掉错误
提供用户友好的错误信息
实现错误重试机制
避免记录敏感信息
使用结构化日志
设置适当的日志级别
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.ts
src/main/**/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
Main to Renderer: Use EventBus to broadcast events via mainWindow.webContents.send()
Use Electron's built-in APIs for file system and native dialogs
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.ts
src/main/presenter/**/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
One presenter per functional domain
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.ts
src/main/presenter/llmProviderPresenter/providers/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
src/main/presenter/llmProviderPresenter/providers/*.ts: Create provider file in src/main/presenter/llmProviderPresenter/providers/ when adding a new LLM provider
Implement coreStream method following standardized event interface in LLM provider files
src/main/presenter/llmProviderPresenter/providers/*.ts: Each file insrc/main/presenter/llmProviderPresenter/providers/*.tsshould 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 acoreStreammethod that yields standardized stream events to decouple the main loop from provider-specific details.
ThecoreStreammethod 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 asformatMessages,convertToProviderTools,parseFunctionCalls, andprepareFunctionCallPromptas 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., usingconvertToProviderTools) 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_star...
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/development-setup.mdc)
**/*.{js,jsx,ts,tsx}: 使用 OxLint 进行代码检查
Log和注释使用英文书写
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.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/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.ts
src/main/**/*.{ts,js,tsx,jsx}
📄 CodeRabbit Inference Engine (.cursor/rules/project-structure.mdc)
主进程代码放在
src/main
Files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.tssrc/main/presenter/configPresenter/modelDefaultSettings.ts
src/main/presenter/configPresenter/**/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
Centralize configuration in configPresenter/
Files:
src/main/presenter/configPresenter/modelDefaultSettings.ts
🧠 Learnings (3)
📚 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 yield reasoning events in the standardized format when applicable.
Applied to files:
src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.tssrc/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.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 : 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.
Applied to files:
src/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.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 files should implement helper methods such as `formatMessages`, `convertToProviderTools`, `parseFunctionCalls`, and `prepareFunctionCallPrompt` as needed for provider-specific logic.
Applied to files:
src/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.ts
🔇 Additional comments (4)
src/main/presenter/configPresenter/modelDefaultSettings.ts (2)
720-730: o3 family additions look consistentNew o3, o3-pro, o3-mini, and o3-preview entries consistently include reasoning: true and reasoningEffort with sensible defaults, and correct max/context values. Good coverage for reasoning models.
Also applies to: 732-742, 744-753
716-718: Reasoning effort propagation across existing entries is coherentAdding reasoningEffort to o3, o4-mini, o1-preview, o1-mini, and o1 ensures downstream providers can apply consistent API parameters.
Also applies to: 764-766, 874-876, 886-888, 910-912
src/main/presenter/llmProviderPresenter/providers/openAIResponsesProvider.ts (2)
231-238: Good: Apply reasoning to all models via modelConfigMoving modelConfig retrieval outside the GPT-5 guard and setting requestParams.reasoning based on it brings parity across Responses API calls.
576-581: Streaming path: reasoning propagation LGTMApplying reasoning for all models in the streaming Responses path is consistent with openAICompletion.
| id: 'o1-pro', | ||
| name: 'OpenAI o1 Pro', | ||
| temperature: 0.7, | ||
| maxTokens: 65536, | ||
| maxTokens: 32768, | ||
| contextLength: 128000, | ||
| match: ['o1-mini'], | ||
| match: ['o1-pro'], | ||
| vision: true, | ||
| functionCall: false, | ||
| reasoning: true | ||
| reasoning: true, | ||
| reasoningEffort: 'high' | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Confirm model ID mapping and downstream usage for o1-pro
The o1-pro block changes include maxTokens and match: ['o1-pro'] with reasoningEffort: 'high'. Verify any UI or provider-side heuristics relying on 'o1-mini' are not implicitly tied to this new 'o1-pro' high-effort profile.
Run this to check for hard-coded 'o1-mini' expectations in the repo:
🏁 Script executed:
#!/bin/bash
# Search for o1-mini/o1-pro references with nearby context
rg -n -C3 -P '\bo1-(mini|pro)\b' --type=ts --type=tsx --type=js --type=jsxLength of output: 104
🏁 Script executed:
#!/bin/bash
# Retry searching for o1-mini/o1-pro references across TS/JS files using glob patterns
rg -n -C3 -e '\bo1-(mini|pro)\b' -g '*.ts' -g '*.tsx' -g '*.js' -g '*.jsx'Length of output: 5571
🏁 Script executed:
#!/bin/bash
# Check if providerModelSettings.ts includes a mapping for 'o1-pro'
rg -n "id: 'o1-pro'" -C3 src/main/presenter/configPresenter/providerModelSettings.tsLength of output: 92
🏁 Script executed:
#!/bin/bash
# Verify any mention of 'o1-pro' in providerModelSettings.ts
rg -n -w "o1-pro" src/main/presenter/configPresenter/providerModelSettings.ts || echo "No occurrences found"Length of output: 128
Missing provider-side mapping for o1-pro
While both openAIResponsesProvider.ts and openAICompatibleProvider.ts list 'o1-pro' in their OPENAI_REASONING_MODELS arrays, the UI’s providerModelSettings.ts has no entry for id: 'o1-pro'. Without this block, selecting “OpenAI o1 Pro” in the UI will fall back or error.
Please add a corresponding settings object in src/main/presenter/configPresenter/providerModelSettings.ts, for example:
{
id: 'o1-pro',
name: 'o1 Pro',
temperature: 0.7,
maxTokens: 32768,
contextLength: 128000,
match: ['o1-pro'],
vision: false, // or true if matching defaultSettings
functionCall: false,
reasoning: true
},— Ensure the fields align with the defaults in modelDefaultSettings.ts (lines 890–898).
🤖 Prompt for AI Agents
In src/main/presenter/configPresenter/providerModelSettings.ts add a settings
object for id 'o1-pro' (matching modelDefaultSettings.ts lines 890–900) so the
UI can map the provider model; include the same fields/values: id: 'o1-pro',
name: 'OpenAI o1 Pro' (or 'o1 Pro' per project convention), temperature: 0.7,
maxTokens: 32768, contextLength: 128000, match: ['o1-pro'], vision: true,
functionCall: false, reasoning: true (and include reasoningEffort: 'high' if
that property is used elsewhere), and insert it into the providerModelSettings
array alongside the other provider entries.
| if (modelConfig.reasoningEffort) { | ||
| ;(requestParams as any).reasoning_effort = modelConfig.reasoningEffort | ||
| } | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Broadened reasoning_effort is good, but apply it to non-streaming path too
You apply reasoning_effort in the streaming path (handleChatCompletion), but the non-streaming openAICompletion path doesn’t set it. That creates inconsistent behavior for the same model depending on call path.
Within openAICompletion, retrieve modelConfig and apply reasoning_effort similarly:
const requestParams: OpenAI.Chat.ChatCompletionCreateParams = {
messages: this.formatMessages(messages),
model: modelId,
stream: false,
temperature: temperature,
...(modelId.startsWith('o1') ||
modelId.startsWith('o3') ||
modelId.startsWith('o4') ||
modelId.startsWith('gpt-5')
? { max_completion_tokens: maxTokens }
: { max_tokens: maxTokens })
}
+ // Align reasoning across non-streaming path
+ const modelConfig = this.configPresenter.getModelConfig(modelId, this.provider.id)
+ if (modelConfig?.reasoningEffort) {
+ ;(requestParams as any).reasoning_effort = modelConfig.reasoningEffort
+ }Do you want me to open a small follow-up PR to add this and tests?
📝 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.
| if (modelConfig.reasoningEffort) { | |
| ;(requestParams as any).reasoning_effort = modelConfig.reasoningEffort | |
| } | |
| const requestParams: OpenAI.Chat.ChatCompletionCreateParams = { | |
| messages: this.formatMessages(messages), | |
| model: modelId, | |
| stream: false, | |
| temperature: temperature, | |
| ...(modelId.startsWith('o1') || | |
| modelId.startsWith('o3') || | |
| modelId.startsWith('o4') || | |
| modelId.startsWith('gpt-5') | |
| ? { max_completion_tokens: maxTokens } | |
| : { max_tokens: maxTokens }) | |
| } | |
| // Align reasoning across non-streaming path | |
| const modelConfig = this.configPresenter.getModelConfig(modelId, this.provider.id) | |
| if (modelConfig?.reasoningEffort) { | |
| ;(requestParams as any).reasoning_effort = modelConfig.reasoningEffort | |
| } |
🤖 Prompt for AI Agents
In src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.ts
around lines 566–569, the code sets reasoning_effort on the streaming path but
not on the non-streaming openAICompletion path, causing inconsistent behavior;
update openAICompletion to retrieve the same modelConfig and, if
modelConfig.reasoningEffort is present, set (requestParams as
any).reasoning_effort = modelConfig.reasoningEffort before sending the request
so both paths behave identically, and add/adjust unit tests to cover the
non-streaming path including reasoning_effort being passed.
💡 Verification agent
🧩 Analysis chain
Confirm Chat Completions API expects 'reasoning_effort' vs 'reasoning: {effort}'
SDKs differ between Chat Completions and Responses. You’re using reasoning_effort here (Chat), and reasoning: { effort } in the Responses provider. That may be correct, but worth double-checking against the SDK version you ship.
🌐 Web query:
For OpenAI Chat Completions API with o3/o4/gpt-5 models, is the correct parameter 'reasoning_effort' (string) or 'reasoning: { effort: "low|medium|high" }'? Provide official docs reference for the Node SDK.
💡 Result:
Short answer
-
For the newer reasoning models (o3, o4-mini, GPT‑5) you should use the Responses API and pass a reasoning object: reasoning: { effort: "low" | "medium" | "high" } (Node SDK: client.responses.create(..., reasoning: { effort: ... })). (openai.com, cookbook.openai.com)
-
The older Chat Completions / some o1-family docs reference a single string parameter named reasoning_effort (e.g. reasoning_effort: "low"|"medium"|"high"); that parameter was model-specific (o1 family / early previews). For new reasoning-capable models OpenAI’s docs and cookbook show the Responses API + reasoning object as the canonical usage. (openai.com)
Minimal Node example (Responses API)
- Example usage with the Node SDK (pass the reasoning object to client.responses.create):
const resp = await client.responses.create({
model: "o4-mini",
input: "Solve this multi-step math problem...",
reasoning: { effort: "high" }
});
// resp.output_text or resp.output contains the results
Official doc pages (references)
- Responses API — new features / reasoning usage (shows reasoning: { effort: ... } and code examples). (openai.com)
- Cookbook / “Better performance from reasoning models” (examples and JSON showing reasoning in responses). (cookbook.openai.com)
- GPT‑5 announcement (mentions reasoning_effort parameter and minimal option). (openai.com)
- Cookbook “Handling function calls with reasoning models” (more examples using reasoning: { effort: ... }). (cookbook.openai.com)
If you want, I can:
- paste a full Node.js sample (with imports and error handling) using the official Node SDK; or
- check your exact current SDK version and show the exact call signature that matches it. Which would you prefer?
Citations:
- 1: https://openai.com/index/new-tools-and-features-in-the-responses-api/?utm_source=chatgpt.com
- 2: https://cookbook.openai.com/examples/responses_api/reasoning_items?utm_source=chatgpt.com
- 3: https://openai.com/index/introducing-gpt-5-for-developers?utm_source=chatgpt.com
- 4: https://openai.com/index/new-tools-and-features-in-the-responses-api/?utm_source=chatgpt.com
- 5: https://cookbook.openai.com/examples/responses_api/reasoning_items?utm_source=chatgpt.com
- 6: https://openai.com/index/introducing-gpt-5-for-developers?utm_source=chatgpt.com
- 7: https://cookbook.openai.com/examples/reasoning_function_calls?utm_source=chatgpt.com
Double-check reasoning parameter usage for new models
The Chat Completions API only supports the legacy reasoning_effort string (on o1-family/preview models). For o3/o4/GPT-5 you must instead call the Responses API (client.responses.create) and pass a reasoning object:
// legacy Chat Completions provider (o1-family)
if (modelConfig.reasoningEffort) {
;(requestParams as any).reasoning_effort = modelConfig.reasoningEffort
}
// for o3/o4/GPT-5 (Responses API)
const resp = await client.responses.create({
model: modelConfig.name,
input: requestParams.messages,
reasoning: { effort: modelConfig.reasoningEffort }
})• Verify which models this presenter supports and ensure that for any o3/o4/GPT-5 variants you switch to the Responses API.
• Update this file accordingly or guard the existing code so reasoning_effort is only used on legacy models.
References:
https://openai.com/index/new-tools-and-features-in-the-responses-api/?utm_source=chatgpt.com
https://cookbook.openai.com/examples/responses_api/reasoning_items?utm_source=chatgpt.com
🤖 Prompt for AI Agents
In src/main/presenter/llmProviderPresenter/providers/openAICompatibleProvider.ts
around lines 566-569, the code unconditionally sets the legacy reasoning_effort
field which only works for o1-family/preview Chat Completions; update the logic
to detect model family/name and only set (requestParams as any).reasoning_effort
for legacy o1-family models, and for o3/o4/GPT-5 variants switch to calling the
Responses API (client.responses.create) passing model and input and a reasoning
object { effort: modelConfig.reasoningEffort }; alternatively add a guard so
reasoning_effort is not sent for newer models and the presenter uses the
Responses API with the reasoning object when modelConfig.name indicates
o3/o4/GPT-5.
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
src/renderer/src/components/settings/ModelConfigDialog.vue (1)
403-410: Temperature validation misses NaN/Infinity; invalid values can slip through and be savedWhen users clear the numeric input,
v-model.numbercan produceNaN. The current checks (< 0/> 2) won’t catchNaN, so the form remains “valid” and saves an invalid value. Providers may then receiveNaN.Apply this diff to harden validation with a finite check:
- // 验证温度 (仅对不支持推理努力程度的模型) - if (!supportsReasoningEffort.value && config.value.temperature !== undefined) { - if (config.value.temperature < 0) { - errors.value.temperature = t('settings.model.modelConfig.validation.temperatureMin') - } else if (config.value.temperature > 2) { - errors.value.temperature = t('settings.model.modelConfig.validation.temperatureMax') - } - } + // Validate temperature only for models that don't support reasoningEffort + if (!supportsReasoningEffort.value && config.value.temperature !== undefined) { + const temp = Number(config.value.temperature) + if (!Number.isFinite(temp)) { + // Reuse min error key to avoid introducing a new i18n key here + errors.value.temperature = t('settings.model.modelConfig.validation.temperatureMin') + } else if (temp < 0) { + errors.value.temperature = t('settings.model.modelConfig.validation.temperatureMin') + } else if (temp > 2) { + errors.value.temperature = t('settings.model.modelConfig.validation.temperatureMax') + } + }
🧹 Nitpick comments (2)
src/renderer/src/components/settings/ModelConfigDialog.vue (2)
136-165: Gate “reasoning effort” by both support and the reasoning toggle to reduce UI confusionShowing the selector even when
config.reasoningis off can confuse users. Consider displaying it only when the model supports reasoningEffort and reasoning is enabled.Also, keep comments in English.
Apply this diff:
- <!-- 推理努力程度 (支持推理努力程度的模型显示) --> - <div v-if="supportsReasoningEffort" class="space-y-2"> + <!-- Reasoning effort (visible only for models that support it and when reasoning is enabled) --> + <div v-if="supportsReasoningEffort && config.reasoning" class="space-y-2">
498-499:supportsReasoningEffortderived from config presence can be brittle; prefer model capabilityUsing “property presence” on the user’s current config can flip the UI unexpectedly (especially given defaults). Prefer deriving support from model defaults/capabilities when available, falling back to presence only if needed.
Example approach (optional):
const supportsReasoningEffort = computed(() => { // Prefer provider/model defaults if accessible // (pseudo-code; adjust based on your actual store shape) const defaults = (settingsStore as any)?.modelDefaults?.[props.providerId]?.[props.modelId] if (defaults && defaults.reasoningEffort != null) return true // Fallback to runtime config presence const v = config.value.reasoningEffort return v === 'minimal' || v === 'low' || v === 'medium' || v === 'high' })Verification steps:
- Confirm that non-reasoning models do not get
reasoningEffortin their default model config.- Confirm that the initial dialog open state displays temperature for non-reasoning models (no flicker from hidden-to-visible).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
src/renderer/src/components/settings/ModelConfigDialog.vue(4 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{ts,tsx,js,jsx,vue}
📄 CodeRabbit Inference Engine (CLAUDE.md)
Use English for logs and comments
Files:
src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/**/*.vue
📄 CodeRabbit Inference Engine (CLAUDE.md)
src/renderer/src/**/*.vue: Use Composition API for all Vue 3 components
Use Tailwind CSS with scoped styles for styling
Organize components by feature in src/renderer/src/
Follow existing component patterns in src/renderer/src/ when creating new UI components
Use Composition API with proper TypeScript typing for new UI components
Implement responsive design with Tailwind CSS for new UI components
Add proper error handling and loading states for new UI componentsUse scoped styles to prevent CSS conflicts between components
Files:
src/renderer/src/components/settings/ModelConfigDialog.vue
src/renderer/src/**/*.{ts,tsx,vue}
📄 CodeRabbit Inference Engine (CLAUDE.md)
src/renderer/src/**/*.{ts,tsx,vue}: Use Pinia for frontend state management
Renderer to Main: Use usePresenter.ts composable for direct presenter method calls
Files:
src/renderer/src/components/settings/ModelConfigDialog.vue
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/**/*.{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.
Files:
src/renderer/src/components/settings/ModelConfigDialog.vue
⏰ 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)
extend reasoningEffort support to all reasoning models
Summary by CodeRabbit
New Features
Changes