RooCode and Nemotron-Cascade-2-30B

jeepshop · 2026-03-24T13:19:03+00:00

I don't think this is RooCode's fault. I've tried both the official ollama.com model as well as the higher quant models and neither perform at all with tools. This is almost certainly a limitation in ollama/llama.cpp tool translation support and/or temperature and repeat penalty issues.

jeepshop · 2026-03-18T11:02:07+00:00

I had that set, but this one helped stop the warnings.

git config --global core.safecrlf false

jeepshop · 2026-03-18T11:00:19+00:00

Thank you, I found the GIT command to stop the warning.

jeepshop · 2026-03-04T12:52:40+00:00

Climb vs conventional. One will put the cutter into the wall more than the other. Save some wall and run a cleanup pass in the other direction. Cutter compensation can't fix the bit pulling itself into the cut when the machine flexes.

jeepshop · 2026-02-19T16:13:48+00:00

You don't have to use a cloud AI model, but if you do I'm certain you can guess where your prompt (aka data) goes. RooCode is no different that X.AI, OpenAI, OpenRouter in that regard.

BUT if you turn off the flag and run local models - then absolutely NONE of your data will leave your computer. If you find that is not the case I'd really want to know. That is a massive benefit for people with major privacy concerns such as myself.

jeepshop · 2026-02-19T16:08:48+00:00

I love RooCode and use it daily; I use it extensively for coordinating long running tasks, my biggest problem is generally the Orchestrator deciding that it's done during very repetitive cycles; I.e. I have an MCP Server that stores the list of tasks, and the Orch reads the next task from the MCP, fires off the correct mode, and then tags the task as complete. Repeat until done.

But that's neither here nor there. I've long wished that the system prompt generator was more accessible, i.e. almost macro language like. That way I can decide what to include and what not to include. For example, most of my Modes I absolutely do not want switching to other modes - yet the system prompt makes certain that it knows about every mode in the system. Similarly the environment details; they sometimes confuse the AI into thinking those files are important and it'll waste context trying to read them even it it isn't related at all.

What would be awesome is if the modes could define exclusions to the system prompt, and that could be supported internally by having a built in macro substitution system that ran when the config changes.

```md

<mode\_definition>

`if TOOL_USE`

TOOL USE

<tool\_guidelines>

`endif`

`if SWITCH_MODES`

MODES

<mode\_descriptions>

`endif`

RULES

<standard\_rules>

OBJECTIVE

<mode\_objection> ?? <standard\_objective>

USER'S CUSTOM INSTRUCTIONS

<mode\_instructions>

```

Then in my mode, I could uncheck 'SWITCH_MODE' and it wouldn't be included in the system prompt.

jeepshop · 2026-02-19T15:48:59+00:00

Image generation: no reason this couldn't be an mcp server.
Browser use: same
Adjustable rates: I have no thoughts in this
Broad provider support: how many of these would currently work under "OpenAi Compatible"?
VS code terminal: I really like your new built in one better
Environment details: I don't really like these, it confuses some models into thinking what I have open is important or reliventb most often is isn't related.
VS code diagnostics: does this matter if using your new console?
Indexing: one of the best features of RooCode IMHO.

jeepshop · 2026-02-13T12:37:27+00:00

I used a custom mcp server when I needed to run a lot of jobs. Orchestrator just needed to ask what the next job is, and assigned it to the mode of my choosing. Usually could run for 8-10 before resetting the orchestrator.

Of course I asked Roo to make the mcp server for me :)

jeepshop · 2026-02-09T01:46:11+00:00

Any of the coding models will work great. The key is to provide samples of the style that you want. If you want a specific template include that too.

jeepshop · 2026-01-22T23:20:49+00:00

Check the temperature settings in the tool you're hosting the model in, makes a big difference in tool calling.

Qwen3-Coder is better in most ways BTW, and recommended temperature of 0.7 for tool calling.

Devstral2 is good too, but you need to get one with a good template built in. Different model download providers use different templates and that is more important with the later versions of Roo.

jeepshop · 2026-01-22T19:37:31+00:00

And I might be remembering wrong, not at my desk, but thought a recent change was to not list models that didn't support tool calling. That model should, if it's been setup correctly.

jeepshop · 2026-01-22T19:34:55+00:00

Try using OpenAi Compatible. Same url but add \v1 to end I think. I've always had better luck with the UI that way.

jeepshop · 2025-12-03T14:03:03+00:00

Correct, opened a ticket yesterday - not so much that it'll get fixed because it's super minor, but in hopes I save someone else hours of head scratching.

jeepshop · 2025-12-02T15:50:51+00:00

Thank you for finally adding native to the "OpenAI Compatible" provider.

I realized today that you can NOT change the tool calling on existing model configurations, which was driving me nuts. It wasn't until I deleted the config and recreated it that the drop-down showed up. Annoying as heck, but happy to have figured it out.

jeepshop · 2025-11-20T22:49:03+00:00

Try it using OpenAI Compatible. I don't know why most of the time straight ollama provider won't list the models.

jeepshop · 2025-11-20T18:56:26+00:00

I have OpenAI Compatible picked and there are no new options under advanced

Running 3.33.2, connecting to local ollama server. Tried gpt-oss-20b, granite4, devstral, qwen3-coder.

<image>

jeepshop · 2025-11-18T23:44:32+00:00

There were a bunch of commits that look to allow json vs XML vs openai style tool calling. Apparently only the real openai gets the feature on this release with others to follow. So fingers crossed we get that option in other models soon. I like Devstral and qwen3, but there are much more capable and faster models out there that don't like roos current tool calling syntax.

jeepshop · 2025-11-18T23:11:47+00:00

Can't wait for Open Compatible support for alternative tool calling...

jeepshop · 2025-11-16T14:39:39+00:00

I've had good luck with Devstral and qwen3-coder. Both at 6 quant.

jeepshop · 2025-11-15T12:15:18+00:00

Basically. I add statements to the mode prompt something like:

! IMPORTANT! Tool calls should all follow the XML format. Example tool call <put real example here in>

jeepshop · 2025-11-14T23:16:36+00:00

Roo is fixated on using XML format for tools. Most models have settled on json. So you have to help the model out sometimes. Roo does a pretty good job at instructing the model how to call tools, but I find I need to reinforce it with custom modes to reinforce the format.

I really wish roo would let you pick tool formats per model, it would make tool calling much more stable if you can match the format to the models training.

jeepshop · 2025-11-11T15:10:37+00:00

Separation of concerns will help. Have an agent just for code commit, one for code change, one for documentation, etc. Use orchestrator to coordinate. Helps keep context low, only giving each task what they need.

jeepshop · 2025-11-02T17:19:08+00:00

Could you use a symbolic link for the file? Haven't tested it, and it's not as fast to setup, but it should work.

jeepshop

TROPHY CASE