[BUG] All open source models stopped working

[m-ibm]

Problem (one or two sentences)

I am using llama maverick, mistral medium/large and gpt oss models through two separate internal platforms.
The connection to them is through either OpenAI Compatible or LiteLLM providers.

For the last few days none of the work; the errors are Provider error mostly 503 errors, sometimes 404.
RooCode claims that (1) model did not provide assistant messages, (2) the reply was empty, (3) the model replied with text instead of invoking a tool, etc

Below is an example of the errors:

Date/time: 2026-01-06T08:22:27.944Z
Extension version: 3.37.0
Provider: openai
Model: mistralai/Mistral-Large-3-675B-Instruct-2512

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.

It is unlikely that all model under two different platforms stopped working at the same time, so this must be a RooCode change in the last 1-2 versions (I have auto-update).

Context (who is affected and when)

Everyone using these internal platforms

Reproduction steps

Since the platform is internal I cannot provide reproduction steps, however, these errors happen consistently when the model needs to invoke some tool.

RooCode v3.37.0
macOS 26.1

Expected result

I expect the tools to be invoked as before. Note that tools work through MCP inspector.

Actual result

Provider error messages

Variations tried (optional)

No response

App Version

v3.37.0

API Provider (optional)

OpenAI Compatible

Model Used (optional)

N/A

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I have analyzed this issue and here is my diagnosis and proposed implementation plan:

Root Cause Analysis

The issue in v3.37.0 is caused by a combination of factors introduced with the native tool protocol changes (PR #10281):

1. resolveToolProtocol() always returns NATIVE for new tasks (src/utils/resolveToolProtocol.ts:44) - The comment states "All models now support native tools; XML is deprecated"

2. OpenAI-compatible handler defaults supportsNativeTools: true (src/api/providers/openai.ts:298-301) - Uses NATIVE_TOOL_DEFAULTS which sets this to true

3. LiteLLM fetcher sets supportsNativeTools: true for ALL models (src/api/providers/fetchers/litellm.ts:48)

4. Task.ts sends native tool definitions when both conditions are met (src/core/task/Task.ts:3899-3900):

   • Task protocol is NATIVE
   • modelInfo.supportsNativeTools is true

The Problem: Not all open source models properly support the OpenAI function calling format. When these models receive native tool definitions, they may:

• Return text instead of proper tool calls (causing "no tools used" error)
• Return malformed/incomplete tool calls
• Return empty responses (causing "no assistant messages" error)
• Fail with server errors (503, 404) because the endpoint does not support tools

The assumption "All models now support native tools" is incorrect for many open source models accessed through OpenAI-compatible or LiteLLM endpoints.

Proposed Implementation Plan

I propose implementing a user-configurable toggle to disable native tool calling for specific provider configurations. This allows users to fall back to XML-based tool calling for models that do not properly support native tools.

Option A: Add supportsNativeTools Override to Custom Model Info

1. Add a supportsNativeTools field to the Custom Model Info settings in the OpenAI-compatible provider configuration
2. Modify the OpenAI handler (src/api/providers/openai.ts) to respect user-provided supportsNativeTools value instead of forcing it to true
3. Modify the LiteLLM handler similarly
4. Document that users experiencing this issue can set supportsNativeTools: false in their custom model info

This approach:

• Is minimally invasive
• Gives users control without requiring code changes
• Preserves the native-by-default behavior for known working models
• Could be extended to auto-detect tool support failures and suggest disabling native tools

Option B: Add a Dedicated "Disable Native Tools" Toggle

1. Add a new boolean setting openAiDisableNativeTools (or similar) to the OpenAI-compatible provider settings
2. Modify resolveToolProtocol() to check this setting and return XML when disabled
3. Update the settings UI to expose this toggle

This approach:

• Provides a simpler toggle for users
• Is more discoverable in the UI
• Does not require understanding custom model info

Recommendation

I recommend Option A as it leverages existing infrastructure (custom model info) and provides finer-grained control. However, if user experience is prioritized, Option B would be more accessible.

---

Additional Notes:

• v3.37.1 added "grace retry for empty assistant messages" which helps but does not solve the root cause
• The reporter is on v3.37.0; updating to the latest version may help with retry behavior but the core issue persists
• Some users may have models that partially support tools but behave inconsistently

Please mention @roomote in a comment saying that you approve this plan (and which option you prefer), and I will proceed with the implementation.

[m-ibm]

@roomote option A is a better solution
Please provide example of how and where to set this in custom model info

[roomote]

Thanks @m-ibm for the feedback! I will implement Option A and provide documentation on how to configure supportsNativeTools in the custom model info settings. I will open a PR shortly with the implementation and examples.

[roomote]

I have opened PR #10479 with my attempt at implementing Option A.

How to use:

1. Go to Settings > API Provider > OpenAI Compatible
2. Scroll down to the "Configure the capabilities and pricing for your custom OpenAI-compatible model" section
3. Uncheck the new "Native Tool Calling" checkbox
4. The model will now fall back to XML-based tool definitions instead of native function calling

This should allow users with open source models that do not properly support OpenAI-style function calling to use Roo Code without encountering the "no tools used" or empty response errors.

Feedback welcome!

[hannesrudolph]

We are removing the XML tool calling protocol from the codebase. Keeping two tool calling architectures massively increases complexity. Every fix, every feature, every tool-related issue forces Roo to reason about two completely different execution paths. That slows development, increases bugs, and makes it harder to move Roo forward. It also guarantees that XML users would slowly get stuck with an increasingly outdated experience as improvements land only in the native path.

https://blog.roocode.com/p/sorry-we-didnt-listen-sooner-native