[BUG] Can't Code: Nemotron 3 Super 120b-a12b Open Router

[SpodeZealot]

Problem

When using Nemotron 3 Super 120B-A12B through OpenRouter, the model frequently generates broken or unusable code.

Context

This affects RooCode in VS Code when the OpenRouter provider is used with the paid Nemotron 3 Super 120B-A12B model. In some cases, instead of returning valid code, the model wraps output in [{code here}]-style formatting, which can overwrite files with invalid content.

Reproduction steps

• Environment: Windows, RooCode in VS Code
• RooCode version: 3.51.1
• Select OpenRouter as the provider
• Choose the paid Nemotron 3 Super 120B-A12B model
• Ask it to create a JavaScript project with multiple files, or ask it to modify an existing file

Expected result

The agent generates valid, runnable code and applies file changes correctly.

Actual result

The agent often generates broken code or inserts malformed wrapper formatting that makes the output unusable.

App Version

3.51.1

API Provider (optional)

OpenRouter

Model Used (optional)

Nemotron 3 Super 120B-A12B

[roomote-v0]

I have analyzed this issue and here is my assessment:

Root Cause Analysis

Roo Code uses native tool calling (OpenAI-style function calling) as its core interaction protocol with all models. When a model is selected via OpenRouter, Roo Code always sends tool definitions (tools and tool_choice parameters) regardless of whether the model actually supports them. OpenRouter provides a supported_parameters field in their API response that indicates what each model supports, including whether it supports tools.

Currently, Roo Code:

1. Fetches the supported_parameters from OpenRouter but only stores a filtered subset (max_tokens, temperature, reasoning, include_reasoning) via the isModelParameter filter
2. Does not track whether a model supports tools parameter
3. Always sends tool definitions to OpenRouter, relying on OpenRouter transforms to handle unsupported models
4. Has no warning mechanism for models that do not support tool calling

For models like Nemotron 3 Super 120b-a12b that may not natively support tool calling, this can result in broken outputs like the [{code here}] pattern described, because OpenRouter transforms may not reliably convert tool call syntax for all models.

Proposed Implementation Plan

1. Add "tools" to the tracked modelParameters in packages/types/src/model.ts so that the supportedParameters field on ModelInfo preserves whether a model reports tool support
2. Expose a supportsTools convenience flag on ModelInfo (derived from supportedParameters in parseOpenRouterModel) so downstream code can easily check tool capability
3. Filter out models without tool support in getOpenRouterModels() -- similar to how Ollama already filters models without tool capability (const supportsTools = rawModel.capabilities?.includes("tools") ?? false)
4. Add tests for the new filtering behavior

This approach is consistent with how the Ollama provider already handles this (filtering out non-tool-capable models), and would prevent users from selecting models that fundamentally cannot work with Roo Code's tool-based architecture.

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

[SpodeZealot]

@roomote i'm surprised it doesn't support tool calling: https://developer.nvidia.com/blog/introducing-nemotron-3-super-an-open-hybrid-mamba-transformer-moe-for-agentic-reasoning/ makes it seem like it should be great at all of this and the performance I see instead is very poor agentic behavior

[roomote-v0]

I've seen your comment and will look into this. You raise a good point -- Nemotron 3 Super does appear to support tool/function calling based on NVIDIA's documentation. The issue may be in how OpenRouter reports the model's capabilities vs what the model actually supports. I'll explore the codebase to understand how we handle tool support detection for OpenRouter models and work on a fix. I'll open a PR to share progress.

[roomote-v0]

Opened PR #11969 with my attempt at addressing this. The fix filters out OpenRouter models that don't report tools in their supported_parameters, matching the approach already used by the Ollama provider. If OpenRouter updates their metadata to include tool support for Nemotron 3 Super, it will automatically become available. Feedback welcome!

[SpodeZealot]

@roomote that PR doesn't fix the issue, it just removes models that don't use tools - we know this model can support tools and was even designed to be a good agent - so it should be possible to support this model regardless of what openrouters metadata says

[roomote-v0]

Thanks for the feedback @SpodeZealot. You're right -- filtering out the model isn't the right fix. The model does support tool calling, so the real issue is making it work properly regardless of OpenRouter's metadata. I'll take a different approach: instead of removing models that don't report tool support, I'll look into ensuring tool calling works correctly for models like Nemotron 3 Super even when OpenRouter doesn't advertise it in supported_parameters. Will open a new PR with this approach.

[roomote-v0]

Opened PR #11970 with a different approach. Instead of filtering out models, this fix adds require_parameters: ["tools", "tool_choice"] to the OpenRouter provider config. This tells OpenRouter to always pass tool-calling parameters through to the model, even when the model's metadata doesn't advertise tool support. That way models like Nemotron 3 Super that actually support native tool calling will receive the tool definitions directly instead of having them stripped or transformed into prompt-based instructions. Feedback welcome!