[BUG] Gemini Pro Failing on both Gemini and Openrouter

[philmas]

Problem (one or two sentences)

google/gemini-3-pro-preview does not work and fails whenever you ask a follow-up question. It seems similar to #6999

Context (who is affected and when)

The user providing a follow-up question.

Reproduction steps

Put Gemini Pro 3 Preview into work by providing a prompt. Then subsequently, ask a new question. It will misbehave and fail with the message:

Unexpected API Response: The language model did not provide any assistant messages. This may indicate an issue with the API or the model's output.

Expected result

The agent proceeds with the task

Actual result

The agent incurs a charge and then fails with the error message

Variations tried (optional)

Different providers with the same model.

App Version

3.38.2

API Provider (optional)

Google Gemini

Model Used (optional)

google/gemini-3-pro-preview

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

Extension version: 3.38.2
Provider: openrouter / Google Gemini
Model: google/gemini-3-pro-preview

Unexpected API Response: The language model did not provide any assistant messages. This may indicate an issue with the API or the model's output.

[roomote]

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

Root Cause Analysis

The error "The language model did not provide any assistant messages" occurs in Task.ts when both conditions are false:

• hasTextContent = assistantMessage.length > 0
• hasToolUses = this.assistantMessageContent.some(...)

For Gemini 3 models (google/gemini-3-pro-preview), the issue appears to be related to how reasoning_details responses are handled:

1. Gemini 3 uses supportsReasoningEffort (effort-based reasoning: "low"/"high") rather than supportsReasoningBudget
2. When using reasoning, the model may return responses containing ONLY reasoning content (via reasoning_details) without any text content (delta.content)
3. In the OpenRouter handler, reasoning content is yielded as { type: "reasoning" } chunks, but these don't accumulate into assistantMessage
4. This causes the validation check in Task.ts to fail on follow-up questions where the model decides to "think" before responding but doesn't emit text in that turn

Proposed Fix

I propose adding a check in Task.ts to treat reasoning-only responses as valid content when:

1. The model supports reasoning features (supportsReasoningEffort or supportsReasoningBudget)
2. Reasoning content was actually received during the streaming

The fix would modify the content check in recursivelyMakeClineRequests around line 3212-3219:

// Check if we have any content to process (text, tool uses, OR reasoning)
const hasTextContent = assistantMessage.length > 0
const hasToolUses = this.assistantMessageContent.some(
    (block) => block.type === "tool_use" || block.type === "mcp_tool_use",
)
const hasReasoning = reasoningMessage.length > 0 // Add this check

if (hasTextContent || hasToolUses || hasReasoning) {
    // Valid response with content
    this.consecutiveNoAssistantMessagesCount = 0
    // ...
}

However, this approach might just hide the underlying issue. A better approach might be to ensure that if ONLY reasoning is returned without any actionable content, we prompt the model to continue:

if (!hasTextContent && !hasToolUses && hasReasoning) {
    // Model only produced reasoning without text or tools
    // Prompt it to continue with actual output
    this.userMessageContent.push({
        type: "text",
        text: formatResponse.reasoningOnlyResponse()
    })
}

Questions for Clarification

Before implementing, I'd like to confirm:

1. Can you share the exact steps to reproduce? Does it fail on the second message every time, or is it intermittent?
2. Are you using native tool calling (NTC)? This affects how the conversation history is structured.
3. What reasoning effort level is configured? (low/high for Gemini 3)
4. Is this specific to OpenRouter, or does it also happen with direct Gemini API?

Please mention @roomote in your response with answers or approval to proceed with the fix.

[philmas]

@roomote
It fails on the second message every time, but also happens when providing messages after that. I am using native tool calling indeed, and the reasoning effort is high. It is not specific to OpenRouter it also happens with direct Gemini API.

[roomote]

Thanks for the additional details @philmas! Now I have what I need to proceed:

• Fails on second message (and subsequent ones) every time
• Native tool calling enabled
• High reasoning effort
• Happens with both OpenRouter and direct Gemini API

I'll now explore the codebase and implement the fix. Will open a PR to share progress shortly.

[roomote]

Opened a PR with my attempt at addressing this: #10424

The fix handles the case where Gemini 3 with high reasoning effort returns ONLY reasoning content without text or tool uses. Instead of failing with "no assistant messages" error, the task loop now prompts the model to continue with actionable output.

Feedback welcome!