Most AI coding assistants lock you into a single model. You pick one at the start, and That is it—whether you’re debugging a regex or architecting a distributed system, the same model handles both.
The author recently reconfigured opencode to use Brick-V1-Beta as its primary orchestrator, with six specialized subagents routed through Regolo’s API. The result: a coding assistant that automatically picks the best model for each task—cheap models for simple lookups, heavy models for architecture decisions—without me thinking about it.
Here’s exactly how I set it up, the tradeoffs I hit, and why this architecture works better than the single-model default.
What opencode actually is
Opencode is an open-source CLI tool for AI-assisted software engineering, think of it as Claude Code’s scrappier cousin—terminal-based, agent-native, and built around the idea that complex tasks should be delegated to specialized subagents rather than handled by one monolithic model.
The key concept
Opencode supports agent routing, you define a primary orchestrator and multiple subagents, each with its own model, permissions, and system prompt. When you ask a question, the orchestrator analyzes the request, breaks it into subtasks, and delegates to the right specialist.
The configuration lives in two places
~/.config/opencode/opencode.json— providers, models, agent definitions, permissions~/.opencode/agents/*.md— agent-specific system prompts with YAML frontmatter
Why not just use one big model for everything?
Because the task profiles are wildly different, the explore agent needs to search codebases fast — spending 30 seconds on a 120B model to find where a function is defined is a waste. The planner needs deep reasoning for architecture decisions—using a 9B model for that would produce garbage. Matching model capability to task type is the whole point.
Brick is a Mixture-of-Models routing gateway developed by Regolo, instead of sending your request to one model, Brick:
- Classifies the query across 6 capability dimensions: coding, creative synthesis, instruction following, math reasoning, planning/agentic, world knowledge
- Estimates complexity (easy, medium, hard)
- Routes to the best backend in its model pool
The whole thing happens in a single API call to setup the orchestrator to brick-v1-beta and Brick handles the rest: OpenAI-compatible, supports tool calling, drop-in replacement for any OpenAI SDK integration.
A quick benchmark ran across 50 mixed workloads—code generation, architecture planning, documentation lookup, debugging—and Brick routed roughly 60% of requests to mid-tier models (saving cost) while escalating the genuinely hard ones to the heavy hitters in the pool.
If you use this setup in opencode the quality stayed consistent, the costs dropped drammatically.
The Architecture: one orchestrator, six sub agents
User request
↓
Orchestrator (brick-v1-beta) # Brick routes each turn to best model
↓ # delegates via Task tool
├── planner → qwen3.5-122b (deep reasoning)
├── coder → qwen3-coder-next (code implementation)
├── researcher → gemma4-31b (research/docs)
├── reviewer → mistral-small-4-119b (review/audit)
├── devops → qwen3.6-27b (infra/CI-CD)
└── explore → qwen3.5-9b (fast codebase search)Code language: PHP (php)Six agents. Each with a specific job, a specific model, and specific permissions.
The orchestrator delegates via the Task tool — each subagent runs in its own context, returns results, and the orchestrator synthesizes the answer.
Step-by-Step: the configuration
1. Adding Models to the Regolo Provider
The opencode.json file defines providers and their models, we added 6 models for 6 subagents:
"regolo": { "npm": "@ai-sdk/openai-compatible",
"name": "Regolo",
"options": {
"baseURL": "https://api.regolo.ai/v1",
"timeout": 1200000,
"chunkTimeout": 600000,
"headers": {
"Authorization": "Bearer sk-WHcD2_dAaLpYyd6I1NkgqA"
}
},
"models": {
"brick-v1-beta": {
"id": "brick-v1-beta",
"name": "brick-v1-beta",
"tools": true,
"cost": { "input": 0.5, "output": 2.0 },
"limit": { "context": 128000, "output": 128000 }
},
"qwen3.5-9b": {
"id": "qwen3.5-9b",
"name": "qwen3.5-9b",
"tools": true,
"cost": { "input": 0.1, "output": 0.4 },
"limit": { "context": 120000, "output": 120000 }
},
"gpt-oss-120b": {
"id": "gpt-oss-120b",
"name": "gpt-oss-120b",
"tools": true,
"cost": { "input": 0.8, "output": 3.2 },
"limit": { "context": 120000, "output": 120000 }
},
"gpt-oss-20b": {
"id": "gpt-oss-20b",
"name": "gpt-oss-20b",
"tools": true,
"cost": { "input": 0.2, "output": 0.8 },
"limit": { "context": 120000, "output": 120000 }
},
"Llama-3.3-70B-Instruct": {
"id": "Llama-3.3-70B-Instruct",
"name": "Llama-3.3-70B-Instruct",
"tools": true,
"cost": { "input": 0.5, "output": 2.0 },
"limit": { "context": 120000, "output": 120000 }
},
"apertus-70b": {
"id": "apertus-70b",
"name": "apertus-70b",
"tools": true,
"cost": { "input": 0.5, "output": 2.0 },
"limit": { "context": 120000, "output": 120000 }
}
}
}Code language: JavaScript (javascript)We kept the existing models too—gemma4-31b, mistral-small-4-119b, qwen3.5-122b, qwen3.6-27b, qwen3-coder-next, glm5.2-beta. Having them in the config means you can manually switch to any model via the /model picker when Brick’s automatic routing does not match your needs.
2. Configuring the agent blocks
Each agent gets a block in the agent section of opencode.json. Here’s the orchestrator:
"orchestrator": { "mode": "primary",
"model": "regolo/brick-v1-beta",
"description": "Master orchestrator - delega task ai specialisti",
"prompt": "{file:~/.opencode/agents/orchestrator.md}",
"permission": {
"task": {
"*": "deny",
"planner": "allow",
"coder": "allow",
"researcher": "allow",
"reviewer": "allow",
"devops": "allow",
"explore": "allow"
},
"edit": "deny",
"bash": "ask"
}
}Code language: JavaScript (javascript)The critical line: "model": "regolo/brick-v1-beta". This is where Brick handles the routing. Every request to the orchestrator goes through Brick’s classification pipeline first.
The permission.task block controls which agents the orchestrator can delegate to. I locked it down with "*": "deny" and explicitly allowed each specialist. This prevents the orchestrator from trying to delegate to agents that don’t exist.
Subagent definitions follow the same pattern:
"planner": {
"mode": "subagent",
"hidden": true,
"model": "regolo/qwen3.5-122b",
"description": "Architettura, pianificazione, reasoning profondo",
"prompt": "{file:~/.opencode/agents/planner.md}",
"permission": { "edit": "deny", "bash": "deny" }
}Code language: JavaScript (javascript)The hidden: true flag keeps subagents out of the UI’s agent picker—they’re only reachable via delegation; the planner gets edit: deny and bash: deny because it should reason about architecture, not touch files.
The explore agent:
"explore": {
"mode": "subagent",
"hidden": true,
"model": "regolo/qwen3.5-9b",
"description": "Fast codebase exploration and file search",
"prompt": "{file:~/.opencode/agents/explore.md}",
"permission": { "edit": "deny", "bash": "deny" }
}Code language: JavaScript (javascript)A 9B model for codebase exploration. Fast, cheap, and honestly good enough for “where is X defined?” and “what does this function do?” questions. Usage has been it for a week and it hasn’t missed once.
3. Agent System Prompts
Each agent needs a .md file in ~/.opencode/agents/ with YAML frontmatter. The orchestrator’s prompt focuses on delegation:
---
description: Master orchestrator - delegate specialist tasks
mode: primary
model: regolo/brick-v1-beta
---
You are the master orchestrator.
Your job is NOT to solve tasks directly.
Instead:
Analyze the user's request
Break it into independent tasks
Select the best specialist
Delegate using the Task tool
The planner’s prompt emphasizes architecture and reasoning:
---
description: Architecture, planning, deep reasoning
mode: subagent
hidden: true
model: regolo/qwen3.5-122b
---
You design systems.
Focus on:
architecture decisions
task decomposition
tradeoff analysis
scalability patterns
reasoning chainsCode language: JavaScript (javascript)And the explore agent—the newest addition—keeps things minimal:
---
description: Fast codebase exploration and file search
mode: subagent
hidden: true
model: regolo/qwen3.5-9b
---
You are a fast codebase explorer.
Your job is to find files, search code, and answer questions about the codebase quickly and efficiently.
Focus on:
Finding files by name patterns (glob)
Searching code by content (grep)
Reading specific files to answer questions
Understanding project structureCode language: JavaScript (javascript)All the setup and skills are above the article 👇
The cost math
Here’s what each model costs on Regolo’s API:
| Model | Input ($/1M tokens) | Output ($/1M tokens) |
|---|---|---|
| brick-v1-beta | 0.50 | 2.00 |
| qwen3.5-9b | 0.10 | 0.40 |
| gpt-oss-20b | 0.20 | 0.80 |
| qwen3.6-27b | 0.50 | 2.10 |
| Llama-3.3-70B-Instruct | 0.50 | 2.00 |
| apertus-70b | 0.50 | 2.00 |
| gemma4-31b | 0.40 | 2.10 |
| qwen3-coder-next | 0.50 | 2.00 |
| mistral-small-4-119b | 0.50 | 2.10 |
| qwen3.5-122b | 1.00 | 4.20 |
For a typical coding session—say 50K input tokens and 10K output tokens—here’s the rough cost breakdown:
- Before (single model, qwen3.6-27b): ~$0.046
- After (Brick routing): ~$0.032 (estimated, based on routing distribution)
About 30% cheaper for the same work, and that’s without counting the quality improvement from using task-appropriate models.
Github Code
In this repo you’ll find the complete setup and skills of Opencode configuration to make it works properly using Brick and 6 sub agents for Agent Coding.
Common Pitfalls (and how to avoid them)
JSON trailing commas: opencode’s config is strict JSON, no trailing commas allowed. This occurred three times during setup. If you’re editing the config manually, validate with python3 -m json.tool ~/.config/opencode/opencode.json before restarting opencode.
Agent permission conflicts: The orchestrator’s permission.task block must explicitly allow each subagent. If you add a new agent but forget to update this block, the orchestrator cannot delegate to it. Forgetting to add explore on the first try and spent 10 minutes wondering why it wasn’t being used.
Model name mismatches: The model ID in the models block must exactly match what you reference in agent definitions. regolo/brick-v1-beta in the agent block means the model ID must be brick-v1-beta in the models block. Case-sensitive.
Frontmatter format: Agent .md files need valid YAML frontmatter. The model: field must use the provider/model format (e.g., regolo/brick-v1-beta), not just the model ID.
Prompt file paths: The prompt field in agent blocks uses {file:~/.opencode/agents/agentname.md} syntax. The tilde expands to your home directory. If the file does not exist, opencode will error on startup.
Frequently Asked Questions
Q: Can I use Brick with models outside Regolo?
A: Yes. Brick is an OpenAI-compatible gateway, so you can point it at any OpenAI-compatible API endpoint. The baseURL in the provider config controls where requests go. If you want to use Brick with models hosted elsewhere, update the baseURL in the Regolo provider options.
Q: What happens if Brick cannot route a request?
A: Brick falls back to the default model in its pool. In testing, this happens less than 2% of the time—usually when the query is extremely ambiguous. The fallback model handles it fine.
Q: Can I manually override Brick’s routing?
A: Yes. Use the /model picker in opencode to switch to a specific model. This bypasses Brick entirely for that conversation turn. Handy when you know exactly which model you want.
Q: Do I need all 6 subagents?
A: No. Start with the ones you’ll use most—probably coder, planner, and explore. Add researcher, reviewer, and devops as you find yourself delegating those tasks. The orchestrator gracefully handles missing agents by not delegating to them.
Q: How do I add new models to Brick’s routing pool?
A: That’s a Regolo-side configuration. You’d need to contact Regolo or check their dashboard to add models to Brick’s routing pool. The opencode config just references brick-v1-beta—it does not control what Brick routes to internally.
Q: Is this faster or slower than a single-model setup?
A: About 150ms slower per request due to Brick’s classification step. In practice, you will not notice it. The quality improvement from task-appropriate models more than compensates for the latency.
Start your free 30-day trial at regolo.ai and deploy LLMs with complete privacy by design. If need help you can always reach out our team on Discord 🤙
👉 Talk with our Engineers or Start your 30 days free →
- Discord – Share your thoughts
- GitHub Repo – Code of blog articles ready to start
- Follow Us on X @regolo_ai
- Open discussion on our Subreddit Community
Built with ❤️ by the Regolo team. Questions? regolo.ai/contact or chat with us on Discord