Issue Checklist

• I understand that issues are for feedback and problem solving, not for complaining in the comment section, and will provide as much information as possible to help solve the problem.
• My issue is not listed in the FAQ.
• I've looked at pinned issues and searched for existing Open Issues, Closed Issues, and Discussions, no similar issue or discussion was found.
• I've filled in short, clear headings so that developers can quickly identify a rough idea of what to expect when flipping through the list of issues. And not "a suggestion", "stuck", etc.
• I've confirmed that I am using the latest version of Cherry Studio.

Platform

Windows

Version

v1.7.5

Bug Description

Critical Issue: When users configure custom parameters following official API provider documentation, certain parameters (specifically reasoning_effort) are silently dropped and never sent to the API. This causes configurations to fail without any warning or error message.

The Problem

I'm using Cherry Studio to call the Volcano Engine (Doubao) API via OpenAI-compatible mode. According to https://www.volcengine.com/docs/82379/1399409, I need to pass:

{
"reasoning_effort": "high"
}

I configured this in Cherry Studio's Custom Parameters feature:

• Key: reasoning_effort
• Type: Text
• Value: high

However, when inspecting the actual network request in DevTools, the reasoning_effort field is completely absent from the request payload. The parameter is silently filtered out by Cherry Studio before being sent to the API.

Evidence

1. UI Behavior: I also configured thinking: { type: "enabled" } as a JSON parameter, and this one worked - the chat interface successfully displayed "Deep Reasoning" with duration.
2. Network Inspection: In DevTools Network tab, the Request Payload shows:
   - thinking: {type: "enabled"} ✅ Present
   - reasoning_effort ❌ Completely missing
3. Control Test: I deliberately set reasoning_effort to an invalid value ("high1"), but the API request did not return any error. This confirms the parameter never reaches the server - it's being filtered client-side.

Root Cause (Code Analysis)

After investigating the source code, I found this warning comment in src/renderer/src/types/sdk.ts (lines 82-83):

// WARN: This field will be overwrite to undefined by aisdk if the provider is openai-compatible. Use reasoningEffort instead.
reasoning_effort?: OpenAIReasoningEffort

The Vercel AI SDK's @ai-sdk/openai-compatible provider explicitly overwrites reasoning_effort (snake_case) to undefined. This affects all providers that use OpenAI-compatible mode, including:

• Volcano Engine (Doubao)
• Baichuan
• Moonshot (Kimi)
• Zhipu (GLM)
• Hunyuan
• Silicon Flow
• Any custom/self-hosted OpenAI-compatible APIs

The filtering logic is in src/renderer/src/aiCore/provider/providerConfig.ts (lines 266-276):

// 否则fallback到openai-compatible
const options = ProviderConfigFactory.createOpenAICompatible(baseConfig.baseURL, baseConfig.apiKey)
return {
providerId: 'openai-compatible', // ← This triggers the filtering
options: {...}
}

Why This Is Critical

1. Users follow official API documentation → They configure reasoning_effort as documented
2. Cherry Studio silently drops the parameter → No warning, no error
3. Feature doesn't work → Users think the model doesn't support reasoning
4. Extremely hard to debug → Requires DevTools network inspection to discover

The Custom Parameters feature exists specifically to let users pass arbitrary provider-specific parameters. Silently filtering certain parameters defeats this purpose and violates user expectations.

Steps To Reproduce

I used Volcengine Engine's Doubao 1.8 model throughout the entire process.

1. Add any provider that uses OpenAI-compatible mode (e.g., Volcano Engine/Doubao, or a custom provider)
2. Go to Assistant Settings → Model Settings → Custom Parameters
3. Add a custom parameter:
   - Key: reasoning_effort
   - Type: Text
   - Value: high
4. Send a message to the model
5. Open DevTools (F12) → Network tab → Find the API request → Inspect Request Payload
6. Observe: The reasoning_effort field is missing from the payload
7. (Optional) Also add a JSON parameter thinking with value {"type": "enabled"} - this one will appear in the payload, demonstrating inconsistent behavior

Expected Behavior

When I add a custom parameter reasoning_effort: "high", I expect:

1. The parameter to be included in the API request payload as "reasoning_effort": "high"
2. OR if the parameter cannot be passed, show a warning message explaining why
3. OR auto-convert reasoning_effort to reasoningEffort (the AI SDK's expected format)

The Custom Parameters feature should pass user-defined parameters to the API without silently filtering them.

Relevant Log Output

```shell
DevTools Network inspection shows the parameter missing from Request Payload:
{
"model": "doubao-seed-1.8-thinking-xxx",
"messages": [...],
"thinking": {"type": "enabled"},
// "reasoning_effort" is MISSING - silently filtered
}
```

Additional Context

Workarounds I Found

1. Use reasoningEffort (camelCase) instead of reasoning_effort (snake_case) as the parameter key
2. Wrap in extra_body: Key=extra_body, Type=JSON, Value={"reasoning_effort": "high"}

Suggested Fixes

Option A: Auto-wrap filtered parameters in extra_body to bypass AI SDK filtering:
// In getCustomParameters or buildProviderOptions
if (customParams.reasoning_effort) {
customParams.extra_body = {
...customParams.extra_body,
reasoning_effort: customParams.reasoning_effort
}
delete customParams.reasoning_effort
}

Option B: Auto-convert snake_case to camelCase for known filtered fields:
if (customParams.reasoning_effort && !customParams.reasoningEffort) {
customParams.reasoningEffort = customParams.reasoning_effort
delete customParams.reasoning_effort
}

Option C: Show a UI warning when users add known-filtered parameters

Impact Assessment

This bug affects a large number of users because:

• Many Chinese AI providers (Doubao, Baichuan, Moonshot, Zhipu, Hunyuan, etc.) use OpenAI-compatible mode
• These providers often have custom parameters like reasoning_effort, thinking, etc.
• Users naturally follow official API documentation which uses snake_case
• The silent failure makes this extremely difficult to diagnose