Task Categories
“Category Is the Router”
Routing tasks by category decouples intent from implementation.
Tasks are classified into categories before execution. Each category (quick, deep, visual-engineering, artistry, and more) maps to an agent configuration optimized for that type of work. The model never sees the routing logic. It receives only the appropriate system prompt and tool set for its assigned category.
Architecture Flow
The Problem: One Size Does Not Fit All
A single agent configuration cannot be optimal for every task. Simple edits need speed and low latency, while deep architectural work demands powerful reasoning and broader context. Using the same model and tools for all tasks wastes tokens on simple requests and underdelivers on complex ones. The solution is a category system: classify the task before execution, then route it to a specialized configuration. Each category specifies its own model, temperature, tool set, and system prompt. The dispatch is invisible to the model. It simply receives the correct configuration and proceeds.
Classifier Design: Heuristics Over Model Calls
The classifyInput() function uses rule-based heuristics instead of querying another LLM. Task length, keywords, file types being edited, and the presence of specific patterns such as 'refactor' or 'add test' determine the category. This keeps classification instantaneous and cost-free. The classifier is also pluggable. Plugins can add new categories or override the classification rules for existing ones.
Real Implementation: Agent Selection via Plugin System
In the actual opencode codebase (packages/core/src/plugin/agent.ts), agent selection uses the plugin system rather than a routing table. Agents are registered through plugin hooks (build, plan, general, explore, compaction, title, summary), and each is distinguished by its mode (primary, subagent, all) and a hidden boolean flag. The 'categories' concept in the web application UI exists only for command palette organization. The core runtime selects agents by mode, not by category. Task-specific routing is achieved through agent hierarchy. The build agent, the default primary, dispatches to subagents such as explore or oracle based on the task description.
Design Decisions
Temperature varies by category. Quick tasks use higher temperature for more creative and divergent thinking, while deep tasks use lower temperature for focused and precise reasoning. This is an inexpensive yet effective way to steer model behavior.
Tool availability is restricted per category. A 'quick' agent does not receive write access. It can only read and edit existing files. This provides an additional safety boundary beyond the permission gate.
Comparison: Claude Code
Claude Code routes tasks to appropriate configurations internally but does not expose the routing mechanism. OpenCode's CATEGORIES map is an explicit, configurable routing table. It classifies incoming tasks through input analysis and selects the model, tool set, and system prompt per category (visual tasks receive a vision model, coding tasks receive a code model, and so on). This config-driven approach makes the agent adaptable to different task domains without requiring code changes.
Deep Dive: Design Decisions
Category-First Dispatch
Tasks are classified by category (quick, deep, visual-engineering, etc.) before execution. Each category maps to an agent configuration optimized for that type of work. The model never sees the routing logic.
Categories Are Plugable
New categories can be added via plugin configuration without modifying the core system. Each category specifies model, temperature, tools, and system prompt overrides.