[BUG] Missing parameter "thinking"

[kawayi12318]

Problem (one or two sentences)

When the API provider sets the default value of the parameter "thinking" as "disabled", an error occurs after enabling the "Enable Reasoning Effort" option: OpenAI completion error: 400 Invalid combination of reasoning_effort and thinking type: high + disabled

Context (who is affected and when)

No matter which option you select for "Enable Reasoning Effort", an error will occur.

Reproduction steps

1. Model: ark-code-latest
2. Base URL: https://ark.cn-beijing.volces.com/api/coding/v3
3. Enable Reasoning Effort: high

Expected result

thinking

Actual result

error

Variations tried (optional)

No response

App Version

v3.47.3

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root cause: When using the OpenAI-compatible provider with APIs like VolcEngine (ark-code-latest), enabling "Reasoning Effort" sends reasoning_effort: "high" in the request body, but does NOT send a thinking parameter. VolcEngine's API defaults thinking to disabled when it's not explicitly provided, and the combination reasoning_effort: "high" + thinking: disabled is rejected as invalid (HTTP 400).

The ZAI provider already handles this pattern correctly for GLM-4.7 by sending thinking: { type: "enabled" } via provider options, but the generic OpenAI-compatible handler has no equivalent mechanism.

Proposed fix: Modify src/api/providers/openai.ts to pass thinking: { type: "enabled" } in the request body when reasoning_effort is being sent. The approach would use a custom fetch wrapper on the createOpenAI provider factory so that the thinking field is injected into the JSON body for requests that already contain reasoning_effort. This ensures VolcEngine and similar APIs receive both parameters consistently, while standard OpenAI endpoints (which ignore unknown body fields) remain unaffected.

Specifically:

1. In the OpenAiHandler constructor (src/api/providers/openai.ts), wrap the fetch used by createOpenAI (the default, non-Azure path) so that when the request body includes reasoning_effort, the wrapper also adds thinking: { type: "enabled" }.
2. Add corresponding unit tests in src/api/providers/__tests__/openai.spec.ts to verify the thinking parameter is injected when reasoning effort is active, and omitted otherwise.

This is a targeted, low-risk change:

• It only affects OpenAI-compatible requests that already include reasoning_effort.
• Standard OpenAI APIs silently discard unknown body parameters.
• No UI or settings schema changes are needed.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[kawayi12318]

@roomote approve

[roomote]

I've seen the approval and will proceed with the implementation. I'll inject a thinking: { type: "enabled" } parameter into OpenAI-compatible requests when reasoning_effort is present. I'll open a PR to share progress shortly.

[roomote]

Opened PR #11397 with my attempt at addressing this. The fix injects thinking: { type: "enabled" } into OpenAI-compatible request bodies when reasoning_effort is present but thinking is missing. Feedback welcome!