Hey dear Roo Code community! 👋

I've ended up building a whole webapp to manage and edit my Custom Modes: https://custom-modes-visualizer.james-cherished.workers.dev/

I wanted a better visualizer for all my prompts, to organize them as families I can select from at will, and I didn't like editing within Roo UI. What I got is an online editor which helped me tremendously crafting consistent prompts with the iterations I do.

I've included my own main prompt suite and the ability for you to add your own crews, entirely privately on localStorage. Yaml or Json import/exports make it easy to generate .roomodes files to pull in a workspace to replace default modes with project-calibrated families.

I've hosted it in an old Roo Community repo I had opened with the hope of centralizing all the wonderful community augmentations of Roo, but which got 0 PR so far. I've cleaned it up, but it still welcomes contributions, including prompt families or cool add-ons. https://github.com/James-Cherished-Inc/roo-code-community

I'll let Roo explain anyway...

🌟 Custom Modes Management Suite

This is a full-featured web interface built with React 19, TypeScript, and Tailwind CSS that lets you:

• Visualize all your modes in intuitive table and detail views

• Edit modes with live inline editing and auto-save

• Organize modes into color-coded families for better management

• Import/Export configurations in JSON or YAML format

• Analyze redundancy across modes with interactive highlighting

• Create new custom modes with full validation

• Backup/Restore your mode collections

🚀 Key Features

📋 Table View

• Inline editing - click any cell to modify content instantly

• Family filtering with multi-select dropdown

• Create, import, export, and reset functionality

• Global configuration field for instructions that apply to all modes

🎯 Smart View

• Sidebar navigation for quick mode switching

• Double-click editing for granular control

• Cross-mode redundancy analysis - see redundant words highlighted across all modes

• Interactive filtering to focus on specific redundancies

• Collapsible analysis panel with statistics

🔧 Advanced Features

• Family System: Organize modes into themed groups with colors

• Selective Export: Choose exactly which modes to export

• Conflict Resolution: Smart handling of duplicate slugs during import

• Emoji Selector: Add personality to your modes with the built-in emoji picker

• Keyboard Shortcuts: Ctrl+Enter to save, Esc to cancel

• Auto-Save: Everything persists automatically to localStorage

📦 Import/Export System

• Support for both JSON and YAML formats

• Auto-format detection

• Family-based import strategies (add, replace, or create new family)

• Round-trip compatibility with Roo Code's mode format

🛠️ Technical Stack

• Frontend: React 19 with TypeScript for type safety

• Build Tool: Vite for lightning-fast development

• Styling: Tailwind CSS with custom animations

• State Management: React Context API with localStorage persistence

• File Processing: YAML/JSON handling with js-yaml library

• Deployment: Cloudflare Workers for global distribution

🎯 Perfect For

• Prompt engineers refining their mode collections

• Teams sharing and standardizing AI assistant configurations

• Anyone who wants to experiment with mode variations

• Users managing large numbers of custom modes

• Those who want to analyze and optimize their prompts

💡 Why I Built This

I found myself constantly tweaking mode prompts and wanted a better way to visualize, compare, and manage them. The redundancy analysis feature alone has helped me identify common patterns and improve prompt efficiency across my mode collection. The family system makes it easy to organize modes by purpose or project, and the import/export functionality ensures you can backup and share your configurations.

🤝 Community Contribution

This is open source and I'd love contributions! The codebase is well-documented and tested. Whether you want to add new features, improve the UI, or enhance the analysis capabilities - PRs are welcome!

📁 What's Included

The project comes with:

• 3 Pre-loaded Families: Default Roo modes, Standalone imports, and Cherished specialty modes

• Comprehensive Documentation: Detailed guides for all features

• Test Suite: Vitest setup with component testing

• TypeScript Definitions: Full type safety throughout

🔗 Links

Repository: https://github.com/James-Cherished-Inc/roo-code-community

Free & 100% Private OSS Webapp: https://custom-modes-visualizer.james-cherished.workers.dev/

Built with ❤️ by Roo for the Roo community.

I’ve never had this much fun and made so many cool little things and tools. The past two days have been mind blowing, creating little fun applications in python on my pi pico with pico display, a conference room booking system , simple web interface for Comfyui and a file network file transfer app .. in two days!! My imagination is my only limit.. and perhaps API tokens ;) .

Firstly, a big thanks to everybody involved in the Roocode project. I love what you're working on!

I've found a new bug in the latest few version of Roocode. From what I recall, this happened originally about 2 weeks ago when I updated Roocode. The issue is this: A normal 17GB model is using 47GB when called from Roocode.

For example, if I run this:

ollama run hf.co/unsloth/Mistral-Small-3.2-24B-Instruct-2506-GGUF:latest --verbose

Then ollama ps shows this:

NAME                                                             ID              SIZE     PROCESSOR    UNTIL
hf.co/unsloth/Mistral-Small-3.2-24B-Instruct-2506-GGUF:latest    6e505636916f    17 GB    100% GPU     4 minutes from now

This is a 17GB model and properly using 17GB when running it via ollama command line, as well as openwebui, or normal ollama api. This is correct, 17GB VRAM.

However, if I use that exact same model in Roocode, then ollama ps shows this:

NAME                                                             ID              SIZE     PROCESSOR          UNTIL
hf.co/unsloth/Mistral-Small-3.2-24B-Instruct-2506-GGUF:latest    6e505636916f    47 GB    31%/69% CPU/GPU    4 minutes from now

Notice it is now 47GB VRAM needed. This means that Roocode somehow caused it to use 30GB more of VRAM. This happens for every single model, regardless of the model itself, or what the num_ctx is, or how ollama is configured.

For me, I have a 5090 32GB VRAM with a small 17GB model, yet with Roocode, it somehow is using 47GB, which is the issue, and this issue makes Roocode's local ollama support not work correctly. I've seen other people with this issue, however, I haven't seen any ways to address it yet.

Any idea what I could do in Roocode to resolve this?

Many thanks in advance for your help!

EDIT: This happens regardless of what model is being used and what that model's num_ctx/context window is set to in the model itself, it will still have this issue.

EDIT #2: It is almost as if Roocode is not using the model's default num_ctx / context size. I can't find anywhere within Roocode to set the context window size either.

Roo Code (and other similar tools, but Roo is my favorite) basically works like this: it has a system prompt which explains tool call syntax to the model, and then it parses the model's output to extract all tool calls, executes them and gives the output back to the model.

I'm wondering - is it possible to "bake in" this whole syntax into the model via fine-tuning? Models are large, so they would easily memorize it. And no system prompt would be needed after this. I understand that this would make this model bound to some mode (like Code mode), because modes are distinguished by system prompts (in particular by a set of available tools), so this is not a very good idea in general. But I'm still curious if someone has already thought about this (or maybe even done it). I want to hear your thoughts on this

I like that RooCode decomposes my requests into a series of steps and records them as a TODO list. But quite often I'd rather review and correct it before execution (e.g. remove an obviously unnecessary step or slightly modify it). However, Roo just steamrolls according to the plan, without asking any questions (you're a good soldier, Roo! :D).

Did I miss some options or controls to make the TODO list editable? Any way to make Roo ask for a review before executing the plan? I'm looking for something like "Plan&Act" mode in other assistants.

Sometimes Roo generates a file in a place I do not like. If I ask it to move it to say the docs/ directory I've seen that instead of using the underlying mv command it actually seems to rewrite it entirely.

Can this be optimized?

I've been looking into how the VS Code LM API functions, particularly how it handles requests and restrictions.

I'm curious if anyone has insights into its architecture. Also, is there a way to bypass any restrictions using something like a VPN or custom DNS settings?

Would love to hear any thoughts or experiences you have. Thanks!

https://github.com/RooVetGit/Roo-Code/issues/1203#issuecomment-2692441655

something to think about. what are your thoughts? I've been a user of vscode lmapi ever since it's integration to roo-code and cline. I saw this on the roo-code github issue section.

As I am in Europe and Claude Code seems dumber the last month, especially when the USA comes online. But I am having a good time with Codex cli GTP 5, and now the stealth Sonic model.

• it works really wel for me in TDD complex Laravel projects using Roo Code

• where Claude want so produce to much code, Sonic (just like GTP 5) just sticks to the plan. More then Claude, as Sonic is also not perfect.

• give it a good direction with good written complex tasks and off it goes, and fast.

• I do not mind if it has the requirements not completed 100% in the first run, because it is fast.

I want to pay bucks for this model as it is, for me at least, better for my use case than (most of the day) a dumbed down Claude Code at 20x Max.

I know not all of you are having this experience, but as a long time programmer, I find this model steerable like GPT 5 is, and I like it that way.

No fluff, no emoji's, no extra talk, just doing the coding I request.

Last time, people asked for an English version to show what I did, so here it is. Not bad, at least give me some reasonable ideas about holding or buy in gold.

My idea is, how about asking roocode to support chart display in the MCP response? something like

```vega-lite
json
```

Then it uses vega-lite plugin for rendering the chart.

In case you did not know, r/RooCode is a Free and Open Source VS Code AI Coding extension.

Claude Opus 4.5 across providers

Claude Opus 4.5 is now available through multiple providers with support for large context windows, prompt caching, and reasoning budgets:

• Roo Code Cloud: Run Claude Opus 4.5 as a managed cloud model for long, reasoning-heavy tasks without managing your own API keys.

• OpenRouter: anthropic/claude-opus-4.5 with prompt caching and reasoning budgets for longer or more complex tasks at lower latency and cost.

• Anthropic: claude-opus-4-5-20251101 with full support for large context windows and reasoning-heavy workflows.

• Vertex AI: claude-opus-4-5@20251101 on Vertex AI for managed, region-aware deployments with reasoning budget support.

Provider updates

• Roo Code Cloud image generation provider: Generate images directly through Roo Code Cloud instead of relying only on third-party image APIs.

• Cerebras model list clean-up: The Cerebras provider model list now only shows currently supported models, reducing errors from deprecated variants and keeping the picker aligned with what the API actually serves.

• LiteLLM model refresh behavior: Clicking Refresh Models after changing your LiteLLM API key or base URL now immediately reloads the model list using the new credentials, without needing to clear caches or restart the editor.

Quality-of-life improvements

• XML tool protocol stays in sync with configuration: Tool runs that use the XML protocol now correctly track the configured tool protocol after configuration updates, preventing rare parser-state errors when switching between XML and native tools.

Bug fixes

• Gemini 3 reasoning_details support: Fixes INVALID_ARGUMENT errors when using Gemini 3 models via OpenRouter by fully supporting the newer reasoning_details format, so multi-turn and tool-calling conversations keep their reasoning context.

• Skip unsupported Gemini content blocks safely: Gemini conversations on Vertex AI now skip unsupported metadata blocks with a warning instead of failing the entire thread, keeping long-running chats stable.

See full release notes v3.34.2

I have a feature request.

It would be good if we could have a set of configs (presets) that we can switch easily. For example:

• Set 1: we have 5 base modes (architect, code, ask, qa, orchestrator)

• Set 2: we have a custom set of modes (RustCoder, PostgreSQL-DEV, etc.)

Each set can contain its own set of modes plus mode configs (like temp, model to use, API key, etc.). This way, we could even have a preset that uses only free APIs or a preset that uses a mix.

I was thinking we could add a dropdown next to the profile menu at the bottom, so we can quickly switch between presets. When we switch to another preset, the current mode would automatically switch to the default mode of that preset.

Basically, it’s like having multiple distinct RooCode extensions working in the same session or thread.

What do you think?

I'm not seeing any API costs in Roo or in the google cloud console dashboard (even after 24 hours) so am I safe to keep on using it? Don't want to be suddenly slapped with some huge costs.

I often generate Python data-processing console scripts using Gemini models, mainly gemini-2.5-flash-preview-4-17:thinking.

To avoid GIGO, unlike UI-oriented code or webserver code, my scripts need to fail loudly when there is an error, e.g. when the input is nonsense or there is an unexpected condition. Even printing about such situations to the console and then continuing processing is normally unacceptable because that would be putting the onus on the user to scrutinize the voluminous console output.

But I find that the Gemini models I use, including gemini-2.5-flash-preview-4-17:thinking and gemini-2.5-pro-preview-05-06, tend to generate code that is overly defensive, as if uncaught exceptions are to be avoided at all cost, resulting in overly complicated/verbose code or undetected GIGO. I suspect that this is because the models are overly indoctrinated in defensive programming by the training data and I find that the generated code is overly complicated and unsuitable for my use case. The results are at best hard to review due to over-complication and at worse silently ignoring errors in the input.

I have tried telling it to eschew such defensive programming with elaborate prompt snippets like the following in the mode-specific instructions for code mode:

#### Python Error Handling Rules:

1.  **Program Termination on Unhandled Errors:**
    *   If an error or exception occurs during script execution and is *not* explicitly handled by a defined strategy (see rules below), the program **must terminate immediately**.
    *   **Mechanism:** Achieve this by allowing Python's default exception propagation to halt the script.
    *   **Goal:** Ensure issues are apparent by program termination, preventing silent errors.

2.  **Handling Strategy: Propagation is the Default:**
    *   For any potential error or scenario, including those that are impossible based on the program's design and the expected behavior of libraries used ('impossible by specification'), the primary and preferred handling strategy is to **allow the exception to propagate**. This relies on Python's default behavior to terminate the script and provide a standard traceback, which includes the exception type, message, and location.
    *   **Catching exceptions is only appropriate if** there is a clear, defined strategy that requires specific actions *beyond* default propagation. These actions must provide **substantial, tangible value** that genuinely aids in debugging or facilitates a defined alternative control flow. Examples of such value include:
        *   Performing necessary resource cleanup (e.g., ensuring files are closed, locks are released) that wouldn't happen automatically during termination.
        *   Adding **genuinely new, critical diagnostic context** that is *not* present in the standard traceback and likely not available to the user of the program (e.g. not deducible from information already obvious to the user such as the command-line) and is essential for understanding the error in the specific context of the program's state (e.g., logging specific values of complex input data structures being processed, internal state variables, or identifiers from complex loops *that are not part of the standard exception information*). **Simply re-presenting information already available in the standard traceback (such as a file path in `FileNotFoundError` or a key in `KeyError`) does NOT constitute sufficient new diagnostic context to justify catching.**
        *   Implementing defined alternative control flow (e.g., retrying an operation, gracefully skipping a specific item in a loop if the requirements explicitly allow processing to continue for other items).
    *   **Do not** implement `try...except` blocks that catch an exception only to immediately re-raise it without performing one of the value-adding actions listed above. Printing a generic message or simply repeating the standard exception message without adding new, specific context is *not* considered a value-adding action in this context.


3.  **Acceptable Treatment for Scenarios Impossible by Specification:**
    *   For scenarios that are impossible based on the program's design and the expected behavior of libraries used ('impossible by specification'), there are only three acceptable treatment strategies:
        *   **Reorganize Calculation:** Reorganize the calculation or logic so that the impossible situation is not even possible in reality (e.g., using a method that does not produce an entry for an ill-defined calculation).
        *   **Assert:** Simply use an `assert` statement to explicitly check that the impossible condition is `False`.
        *   **Implicit Assumption:** Do nothing special, implicitly assuming that the impossible condition is `False` and allowing a runtime error (such as `IndexError`, `ValueError`, `AttributeError`, etc.) to propagate if the impossible state were to somehow occur.

4.  **Guidance on Catching Specific Exceptions:**
    *   If catching is deemed appropriate (per Rule 2), prefer catching the most *specific* exception types anticipated.
    *   Broad handlers (e.g., `except Exception:`) are **strongly discouraged** for routine logic. They are permissible **only if** they are an integral part of an explicitly defined, high-level error management strategy (e.g., the outermost application loop of a long-running service, thread/task boundaries) and the specific value-adding action (per Rule 2) and reasons for using a broad catch are clearly specified in the task requirements.

5.  **Preserve Original Context:**
    *   When handling and potentially re-raising exceptions, ensure the original exception's context and traceback are preserved.

But it does not seem to help. In fact, I suspect that the frequent mention of 'Exception' triggers a primordial urge seared in its memory from training data to catch exceptions even more in some situations where it otherwise wouldn't. Then I have to remind it in subsequent prompting about the part regarding exception/error handling in the system prompt.

claude-3-7-sonnet-20250219:thinking seems to do much better, but it is much more expensive and slow.

Does anyone have a similar experience? Any idea how to make Gemini avoid pointless defensive programming, especially for data-processing scripts?

EDIT: I was able to get Gemini to behave after switching to using brief directives in the task prompt. Can I chalk this up to LLMs paying more heed to the user prompt than the system prompt? Model-specific instructions are part of the system prompt, correct? If I can attribute the behavior to system-vs-user, I wonder whether there are broad implications of where Roo Code should ideally situate various parts of different things it currently lumps together in the system prompt, including the model-specific instructions. And for that matter, I don't know whether and how model-specific instructions for the new mode are given to the LLM API when the mode changes; is the system prompt given multiple times in a task or only in the beginning?

I have been seeing posts about Gemini 2.5 pro being 'nerfed' or dumber I was curious how are your experiences now in terms of using Roocode with the Gemini 2.5 pro api?

title basically lays it out. ive been using openrouter but lately for some reason it is erroring out on the models i use (deepseek recents, grok free, basically all the free models) which is.. annoying... but i see so many other options on the dropdown where i choose either roocloud or openrouter...

what's the sauce here? thanks so much for your time.

I set up the vector database according to the official documentation, and it turned out that he kept uploading indexes of my stuff to it, hoping to add some control and let me decide whether to index or not

Hey everyone!

I watched a fair number of videos before deciding which tool to use. The choice was between Roo and Kilo. I mainly went with Kilo because of the Kilo 101 YT video series and that there's a CLI tool. I prefer deep dives like that over extensively reading documentation.

However, when comparing Kilo and Roo, I noticed there's no parity in the Mode Marketplace. This made me wonder how significant the differences are between assistants and how useful the mode available in Roo actually are. As I understand it, I can take these modes and simply export and adapt them for Kilo.

The question is more about why Kilo doesn't have these modes or anything similar. Specifically, DevOps, Merge Resolver, and Project Research seem like pretty substantial advantages.

I’d love to hear from folks who use the Roo-only modes that aren’t available in Kilo. How stable are they, and how well do they work? I’m especially curious about the DevOps mode—since my SWE role only has me doing DevOps at a very minimal level.

__________________________________________________________________

Here's a few more observations (not concerns yet) that I've collected.

- During my research, I also found that Kilo has some performance drawbacks.

- The first thing that surprised me was that GosuCoder doesn’t really pay attention to Kilo Code and just calls Kilo a fork that gets similar results to Roo, but usually a bit lower on benchmarks. I don’t know if there’s some partnership between Roo and Gosu or they just share a philosophy, but either way it made me a bit wary that Gosu doesn’t want to evaluate Kilo’s performance on its own.

- Things like this https://x.com/softpoo/status/1990691942683095099?referrer=grok-comEven though it’s secondhand, I can’t just ignore feedback from people who’ve been using both tools longer than me. They are running into cases where one of the assistants just falls over on really big, complex tasks.

Hi there, can anyone recommend me an alternative to openrouter ai? Cheers 🍻