[BUG] Deepseek 3.2 Error

[Dayclone]

Problem (one or two sentences)

Ive tried the Deepseek 3.2 and 3.2 exp and Speciale but it seems each of these models are failing.

The 3.2-exp seems to sort of work on/off at the moment but the latest release are failing through OpenRouter.

The message I am getting is
"Unexpected API Response: The language model did not provide any assistant messages. This may indicate an issue with the API or the models output."

or

Roo is having trouble...
Roo appears to be stuck in a loop, attempting the same action (read_file) repeatedly. This might indicate a problem with its current strategy. Consider rephrasing the task, providing more specific instructions, or guiding it towards a different approach.

Context (who is affected and when)

Whenever using Deepseek 3.2 to code

Reproduction steps

Use any Deepseek 3.2 models, NOT Speciale as it doesn't have tool calling capabilities. If using OpenRouter choose both Deepseek 3.2 or Deepseek 3.2-exp they will fail and give errors.

I've tried direct as well with Deepseek and it fails to code agentically as well and gives similar errors.

Expected result

The code is successfully completed

Actual result

Error Roo tried to use read_file without value for required parameter 'args (containing valid file paths)'. Retrying...

Variations tried (optional)

No response

App Version

3.35.4

API Provider (optional)

OpenRouter

Model Used (optional)

Deepseek 3.2 & Deepseek 3.2-exp

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 Analysis

The DeepSeek 3.2 models are failing with tool calling errors when used through OpenRouter. The error messages indicate that the models are not being properly configured for the newer DeepSeek V3 models (3.2 and 3.2-exp).

Proposed Solution

1. Add DeepSeek V3 model configurations: The codebase currently only has configurations for deepseek-chat and deepseek-reasoner in the native DeepSeek provider, but doesn't have specific handling for the newer V3.2 models when used through OpenRouter.

2. Update OpenRouter handler: Modify the OpenRouter handler to properly detect and configure DeepSeek V3.2 models:

   • Add model ID pattern matching for deepseek/deepseek-v3, deepseek/deepseek-3.2, and deepseek/deepseek-3.2-exp
   • Ensure these models use the correct message format (they should NOT use R1 format like deepseek-r1 models)
   • Configure appropriate tool calling settings for these models

3. Fix tool parameter handling: The error "read_file without value for required parameter 'args'" suggests the tool calling format may not be correctly parsed for these models. I'll ensure the OpenRouter handler properly formats tool calls for DeepSeek V3 models.

This approach will ensure DeepSeek 3.2 models work correctly through OpenRouter while maintaining compatibility with existing DeepSeek models.

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

[Dayclone]

@roomote Seems logical, please proceed.

[roomote]

I've seen your comment and will explore a potential fix for the DeepSeek 3.2 model issues. I'll implement the proposed solution to add proper DeepSeek V3 model configurations and update the OpenRouter handler. I'll open a PR to share progress.

[roomote]

Opened a PR with my attempt at addressing this: #9782.

The fix ensures that DeepSeek V3 models (v3, 3.2, 3.2-exp) are properly detected and configured to use the standard message format with tool calling support, rather than being incorrectly treated as R1 models. All tests are passing and the changes should resolve the tool calling errors you were experiencing.

Feedback welcome!

[Dayclone]

Worked with Roomote to provide a fix. Waiting code review from code owners.