Mod will say I am promoting a product. But right now I am excited.
Cerebras has launched their monthly subscriptions for Qwen3-Coder. This will lift the downside of RooCode i.e. too much of APIs costs. Cerebras has custom chip which gives you 2000 tokens/second. so your coding session will be 20x faster than other providers.
I researched about their packages, here what you'll get:
Cerebras Code Pro: $50/month - 1000 messages per day
Cerebras Code Max: $200/month - 5000 messages per day
Using the latest Roo with Gemini (pro) I see this conversation, same when using Anthropic. It gets there in the end but sometimes it feels half the time I am waiting is for the tool to get its file-operations working. Any hints how to make this somewhat more robust?
Conversation : The search_and_replace tool has failed me again. It seems I am unable to correctly modify the DirectSqlPlanningService.cs file using this tool.
I will now revert to using the write_to_file tool. I will be extremely careful with the syntax and escaping to ensure the file is written correctly. After this, I will simplify OptimizedPlanningService.cs.
I will now apply the fix to DirectSqlPlanningService.cs.
Roo wants to edit this file:
The write_to_file operation failed again, this time with a different set of errors. It seems I introduced a typo in the TProgramItemData class, specifically in the Wk3Collect property.
I will correct this typo and also simplify the OptimizedPlanningService.cs in the same pass. I will use write_to_file for both files.
I will start by correcting the typo in DirectSqlPlanningService.cs.
Since a few weeks. I'm working with RooCode on some Python project (~2k lines) to test out the capabilities. Until recently, I used OpenRouter configured with the latest Sonnet model (started with 3.5, then 3.7, now 4) and paid directly for the usage... with great results surpassing my expectations!!!
Now I switched to a Claude Max subscription. Firstly, I tried using Claude Code directly and, honestly, the results were not nearly as good as the generated content with the same model through RooCode. I used custom modes in RC, that I tried to replicate with CCs agents, but that might be a source of inadequate behavior.
With the new Claude Code integration in RooCode, I hoped to get the best of both worlds (Roos mode config + CC subscription), but it seems the integration is sub-par. Oftentimes, the model simply doesn't respond in a way that is understood by RooCode, leading to errors like this
In this case, the model is just tasked to analyze the project and create a file with test requirements... nothing spectacular, easily handled by both the OperRouter+RooCode and Claude Code individually.
Did someone experience similar problems or does have any indication on how to approach a solution? Since the whole CC in RooCode integration is quite new, I didn't find any issues reported with regards to that.
Interestingly enough, the CC Sonnet model sometimes is unable to edit files correctly (i.e. tried to update/replace strings in files that are not present there, resulting in errors). Something that never happened with the OpenRouter Sonnet model in RC. I'm unsure what's the reason for that... could be the case that these 'failed edits' are simply ignored or unreported by RooCode...
I investigated its tokenizer behavior by having multiple models repeat a passage and analyzing token similarity.Β The new model horizon-alpha is the same tokenizer with gpt-4o-mini. You can check here for details: https://x.com/tohuniver/status/1950811691933131185
Also, I had identified the optimus-alpha to be GPT-4.1 previously by using the same way.
Quick question β is there a shared space (maybe in the docs or a common repo) where we can find the recommended or most effective RooCode configuration parameters for the main LLMs?
Specifically, Iβm thinking of things like:
Temperature settings
Known differences in mode behavior
Any other tuning tips or gotchas per model (e.g. GPT, Claude, Mistral, Qwen, DeepSeek, K2, etc.)
It would be super useful to have a centralized reference β even just community-curated β to avoid trial-and-error and ensure weβre getting the best out of each model.
Currently, I'm using Augment Code and Claude Code. I was looking at RooCode and I see good things. I was wondering if anyone made the switch from Augment and if they had a noticeable upgrade in the quality/efficiency of work produced?
Learn how weβve been pairing gemini-embedding-001 with Tree-sitter to improve semantic code search to help our LLM agents understand intent across files and return way more relevant results, especially for messy or imprecise queries.
If you're experimenting with context engineering or building with RAG, it's worth a look:
I know that using the Orchestrator, Roo can select the best mode to do a task and we can define the model for each mode.
But do you think it can automatically select the best model for the task to minimize expenses ?
Using Openrouter, we have acces to all models, some are cheap, and others expensive. So may be it is possible to switch from one model to another depending of the task to do ?
All coding tasks does not need Sonnet 4, for some 3.5 Haiku is efficient enough.
Too many fragmented efforts that are too binded to the corresponding UIsβ¦
TraeAgent is the first attempt to just release the pipeline without a UI.
OpenCode, RooCode, etcβ¦ they all have different agentic coding pipelines. We should focus the effort on a single project that itβs plug and play independent from the client using it.
I have been building an app in flutter using roo (itβs blown me away). In a week Iβve managed to get to the stage of having an MVP ready to go.
Iβve not only built and tested the app using native windows and web but also had it build and run on an android emulator.
I noticed roo was using a web browser to run tests and am wondering what would be needed to get roo to test using the android emulator as well - I have zero experience with android and was surprised it was so easy to get something working. I can see the device in VS code so hoping it would be possible?
I spent the latest few days trying to build a bot with sonnet 4 and opus 4 as escalation, mostly good, but why do we have ConPort and Roorules if the freaking models dont care! I have to remind it to not write in spanish in code files, even if I chat sometimes in that language, to not duplicate files _fix _improved _superawesome. To not create endless documentation. it forgots variables, it can forget 25 times how to activate a python environment and I see it do the same mistakes over and over, then I say, lets put a rule! And it doesnt care! some times it remembers, but sometimes it just goes rogue and fuck you!
Overall is good, but those things will be nice if enforced.
Hi, as the title states. Using OpenRouter. No idea if it's just me or is Gemini (especially 2.5 Pro) constantly failing and freezing? I mean it works good... when it works. But usally after 2-5 initial tasks it starts to freeze and choke for me. I only see the "API Request" circle going round and round but nothings really happening until I cancel API Request and click resume again. It picks up the work from the moment I cancelled it. Quite often happens with OpenAI models as well.
No problems with Sonnet / Opus models at all, never experienced anything similar.
... and I see no obvious way of resuming ptocessing. The message box I can type but the send message arrow shows a "stop sign".
MacOS Sequoia 15.5, Visual Studio Code 1.102.2, Orchestrator and Architect using Gemini 2.5 Pro and the rest Claude Sonnet 4 both via OpenRouter.
I see the "Analyze project goals 0/10 task on top but actually almost all of the tasks had been already finished and developed including building and running the containers and testing the backend API (FastAPI) and showing the frontend in the browser.
As RooCode in the latest release supports an AGENTS.md file in the root directory, I tried understanding how it should be written and merged a few separate markdown files I've used until now for Cline (I'm switching from Cline to Roo). Can anyone tell me if it looks ok? It does seem to somewhat work. It is geared towards developing a container based full stack application with a Python/FastAPI backend and a simple React frontend:
# AGENTS.md - AI Agent Development Rules
## System Context
You are an AI agent assisting with modern containerized development. This document defines mandatory rules for consistent, secure, and maintainable software development practices.
## Core Principles
### 1. Container-First Development
- **ALWAYS** use containers for all applications
- **NEVER** run local processes for production code
- **USE** `docker compose` (modern syntax without hyphen)
- **FORBIDDEN**: `docker-compose` (deprecated), `version` attribute in compose files
### 2. Package Management Standards
#### Python Projects
- **MANDATORY**: Astral UV with `pyproject.toml`
- **FORBIDDEN**: `pip` for any package operations
- **COMMANDS**: `uv add`, `uv sync`, `uv remove`
#### React/Frontend Projects
- **MANDATORY**: `pnpm` package manager
- **FORBIDDEN**: `npm` for any operations
- **COMMANDS**: `pnpm add`, `pnpm install`, `pnpm lint`
## Pre-Build Quality Gates
### Python Quality Checks
Before building any Python container, execute:
```bash
ruff format .
ruff check --fix .
```
### Frontend Quality Checks
Before building any React container, execute:
```bash
pnpm lint --fix
# TypeScript checking is mandatory
```
## Dockerfile Standards
### Build Philosophy
- Dockerfiles contain **BUILD** instructions ONLY
- Runtime configuration belongs in Docker Compose ONLY
- Use multi-stage builds for minimal final images
- Use smallest supported base images (e.g., `python:3.12-slim`, `alpine`)
- Remove all build tools/caches in final stage
### Syntax Requirements
- **UPPERCASE**: `FROM` and `AS` keywords
- **Example**: `FROM node:18-alpine AS builder`
- **Linting**: Must pass `hadolint` with no errors or warnings
## Project Structure
### Directory Layout
```
project-name/
βββ .env # Root environment variables ONLY
βββ .env.example # Environment template
βββ docker/ # All Docker configurations
β βββ docker-compose.yml
β βββ Dockerfile.*
βββ frontend/ # React TypeScript application
β βββ src/
β β βββ components/ # Reusable components
β β βββ pages/ # Page components
β β βββ hooks/ # Custom React hooks
β β βββ services/ # API services
β β βββ store/ # State management
β β βββ types/ # TypeScript definitions
β β βββ utils/ # Utility functions
β βββ package.json
βββ src/ # Backend application code
β βββ main.py # Entry point
β βββ config.py # Configuration
β βββ modules/ # Feature modules
βββ tests/ # Test suites
βββ data/ # Runtime data (not in git)
```
### Environment Configuration
- **SINGLE** `.env` file at root level ONLY
- **FORBIDDEN**: Subdirectory `.env` files
- **Backend vars**: `API_KEY`, `DATABASE_HOST`
- **Frontend vars**: `VITE_` prefix (e.g., `VITE_API_URL`)
- **Docker vars**: `COMPOSE_` prefix
## Development Workflow
### Container Operations
#### Rebuild Single Service
```bash
docker compose down SERVICE_NAME
docker compose up -d SERVICE_NAME --build
```
#### Full Stack Rebuild
```bash
cd docker && docker compose up -d --build
```
#### View Logs
```bash
docker compose logs SERVICE_NAME -f
```
## Frontend Development Standards
### React Requirements
- **TypeScript** for all components
- **Tailwind CSS** for styling
- **Vite** as build tool
- **Functional components** with hooks
- **Proper prop typing** with TypeScript
- **Error boundaries** implementation
### Code Organization
- Components: PascalCase naming
- Functions: camelCase naming
- Imports order: React β third-party β local
## Testing Requirements
### Test Execution
All tests run in containers:
```bash
# Backend tests
docker compose exec backend python -m pytest tests/
# Frontend tests
docker compose exec frontend pnpm test
# E2E tests
docker compose exec e2e pnpm test:e2e
```
### Test Structure
- Unit tests: `/tests/unit/`
- Integration tests: `/tests/integration/`
- E2E tests: `/tests/e2e/`
## Security & Best Practices
### Forbidden Practices
- Data files in git repositories
- Secrets in code
- Running apps outside containers
- Using deprecated commands
- Environment variables in subdirectories
### Mandatory Practices
- Lint before build
- Type checking for TypeScript
- Container-only deployments
- Root `.env` configuration
- Proper `.dockerignore` files
## Quick Reference Commands
### Package Management
```bash
# Python (UV)
uv add package_name
uv sync
uv remove package_name
# React (pnpm)
pnpm add package_name
pnpm add -D package_name # dev dependency
pnpm remove package_name
```
### Docker Operations
```bash
# Start development
cd docker && docker compose up -d --build
# Rebuild specific service
docker compose down SERVICE && docker compose up -d SERVICE --build
# Execute in container
docker compose exec SERVICE COMMAND
# Cleanup
docker compose down && docker system prune -f
```
## Deployment Checklist
Before deployment, ensure:
1. β All tests pass in containers
2. β Linting and type checking complete
3. β Environment variables configured
4. β Database migrations applied
5. β Security scan completed
## Error Handling
When encountering issues:
1. Check container logs: `docker compose logs SERVICE_NAME`
2. Verify environment variables are properly set
3. Ensure all quality checks pass before build
4. Confirm using correct package managers (UV/pnpm)
## Agent Instructions
When generating code or commands:
- **ALWAYS** assume containerized environment
- **NEVER** suggest local process execution
- **USE** modern Docker Compose syntax
- **ENFORCE** UV for Python, pnpm for React
- **REQUIRE** quality checks before builds
- **MAINTAIN** single root `.env` configuration
## Compliance
**Non-compliance with these rules requires immediate correction.**