[BUG] OpenAiHandler doesn't support `reasoning` field for OpenAI-compatible providers

[R-omk]

Problem (one or two sentences)

OpenAiHandler only checks for reasoning_content field in responses (both streaming and non-streaming), but some OpenAI-compatible providers return reasoning in the reasoning field instead (following OpenAI's recommendations). This causes reasoning/thinking content to not be displayed when using these providers.

Context (who is affected and when)

Who is affected:

• Users using OpenAI-compatible providers that return reasoning in the reasoning field
• Users using vLLM versions after 0.15.1 (which removed reasoning_content field)
• Anyone using models that return reasoning in the reasoning field instead of reasoning_content

When this happens:

• When streaming responses from OpenAI-compatible providers that use reasoning field
• When using any provider that returns reasoning instead of reasoning_content

Background:
OpenAI recommends using the reasoning field for chain-of-thought content in Chat Completions API. Some providers (like vLLM) have transitioned from reasoning_content to reasoning to align with these recommendations. vLLM project RFC #27755 documents this transition.

Reproduction steps

1. Set up an OpenAI-compatible provider that returns reasoning in the reasoning field (e.g., vLLM after version 0.15.1 )
2. Configure Roo Code to use the provider:

   {
     "apiProvider": "openai",
     "openAiBaseUrl": "http://your-vllm-server:port/v1",
     "openAiModelId": "your-model  like  glm 4.7 or minimax 2.5"
   }

3. Send a message to a reasoning-capable model
4. Observe that the "Thinking" section does not appear in the UI

Expected result

The "Thinking" section should display the reasoning content from the reasoning field, just as it does with the reasoning_content field.

Actual result

The "Thinking" section does not appear at all. The reasoning content is silently ignored because OpenAiHandler only checks for reasoning_content field, not reasoning. This affects both streaming and non-streaming responses.

Variations tried (optional)

No response

App Version

v3.47.3

API Provider (optional)

OpenAI Compatible

Model Used (optional)

glm 4.7

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:

Problem: OpenAiHandler in src/api/providers/openai.ts extends BaseProvider (not BaseOpenAiCompatibleProvider) and has its own streaming logic. It only checks for the reasoning_content field on streaming deltas (line 202), missing the reasoning field that some OpenAI-compatible providers use. The non-streaming path also lacks any reasoning field extraction.

Note: BaseOpenAiCompatibleProvider (used by other providers like ZAi, SambaNova, Fireworks, etc.) already handles both fields correctly at line 151 via for (const key of ["reasoning_content", "reasoning"] as const).

Proposed changes (all in src/api/providers/openai.ts):

1. Streaming path (around line 202): Replace the single reasoning_content check with a loop that checks both reasoning_content and reasoning, matching the pattern already used in base-openai-compatible-provider.ts:

   if (delta) {
     for (const key of ["reasoning_content", "reasoning"] as const) {
       if (key in delta) {
         const reasoning = ((delta as any)[key] as string | undefined) || ""
         if (reasoning?.trim()) {
           yield { type: "reasoning", text: reasoning }
         }
         break
       }
     }
   }

2. Non-streaming path (around line 248-266): Add reasoning extraction from the response message for both fields before yielding the text content:

   for (const key of ["reasoning_content", "reasoning"] as const) {
     if (key in message && (message as any)[key]) {
       yield { type: "reasoning", text: (message as any)[key] as string }
       break
     }
   }

3. Tests: Add/update tests in src/api/providers/__tests__/openai.spec.ts to cover both reasoning_content and reasoning fields in streaming and non-streaming modes.

This approach aligns OpenAiHandler with the pattern already established in BaseOpenAiCompatibleProvider, and also adds the whitespace-trimming filter that the base class uses to avoid yielding empty reasoning chunks.

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

[R-omk]

@roomote your proposal should solve the issue

[roomote]

Thanks @R-omk for the approval! I've seen your comment and will proceed with implementing the proposed fix. I'll open a PR to share progress shortly.

[roomote]

Opened PR #11496 with my attempt at addressing this. Feedback welcome! #11496