Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 10 — Oh-My-OpenCode’s Innovations
Token Usage: ~4,000 input + ~980 output

10.2 Semantic Category System

One of OMO’s smartest ideas is that categories should describe intent, not models. This sounds simple, but it solves a real architectural problem. In many agent systems, prompts or users select models directly: “use GPT-X for this,” “switch to model Y,” and so on. That approach works in the short term, but it couples task semantics to backend infrastructure. OMO introduces an abstraction layer that says: describe the nature of the work first, then let the runtime resolve the best model and fallback chain.

This logic is implemented in files such as src/tools/delegate-task/category-resolver.ts, src/tools/delegate-task/subagent-resolver.ts, src/tools/delegate-task/categories.ts, and src/shared/model-requirements.ts. Together, these files form a small scheduling system. The caller specifies a semantic category like visual-engineering, ultrabrain, quick, deep, or writing; OMO then resolves that category into actual model candidates, variants, and guardrails.

The concrete mappings are revealing. visual-engineering prioritizes Gemini 3 Pro and related high-visual-capability options. ultrabrain prefers GPT-5.3 Codex with a high reasoning variant. quick aims for Haiku 4.5 or similarly fast, low-cost models. deep also centers on GPT-5.3 Codex, but with different activation rules. writing leans toward K2P5 and other writing-friendly fallbacks. These are not arbitrary labels. They encode assumptions about task structure: visual work needs strong multimodal or layout-sensitive reasoning, quick work values latency and cost, deep work values high-end code reasoning, and writing values fluency and long-form composition.

The immediate benefit is operational flexibility. If a model disappears, gets rate-limited, becomes too expensive, or is replaced by a better one, the category interface does not need to change. Users and higher-level agents still say “this is deep work” or “this is quick work.” The resolver layer handles the rest. In software design terms, this is classic indirection: a stable semantic interface above an unstable implementation substrate.

But OMO’s argument goes further. The category system also tries to eliminate model self-perception bias. That phrase deserves explanation. Large models are often prompted with role claims that mention their own identity or expected strengths. If a system says “you are the best creative model” or “you are a fast search model,” some behaviors come not from actual capability routing but from narrative priming inside the prompt. OMO tries to avoid over-relying on that. By assigning tasks through category semantics and resolver code, it shifts more of the intelligence into system architecture and less into the model’s self-description.

This matters because models are unreliable narrators about themselves. Their prompt identity can influence style, confidence, verbosity, and even failure behavior. OMO’s category resolver therefore works as a structural antidote. Rather than asking the model to believe what it is, the runtime decides what it should do based on explicit category requirements and availability checks.

category-resolver.ts shows this clearly. It checks user categories, merged defaults, model availability, explicit overrides, and fallback requirements. If a category has a hard requirement—for example, a particular Codex-class model—then the resolver can reject execution or explain which model is missing. If the preferred model is not available, it walks a fallback chain. It also computes prompt append behavior and unstable-agent flags. In other words, the category is not a cosmetic label. It is a policy bundle.

subagent-resolver.ts complements this by resolving named subagents against available agent configs and their own model requirements. This lets OMO distinguish two orthogonal dimensions: named agents such as Oracle or Explore, and semantic categories such as quick or deep. The agent answers “who should do the job?” The category answers “what kind of job is this?” That separation is elegant.

Another advantage is that categories improve prompt portability. A higher-level orchestrator can write reusable task templates like:

• use visual-engineering for UI implementation,
• use quick for small obvious edits,
• use writing for docs,
• use ultrabrain for difficult reasoning.

Those templates survive model churn much better than hard-coded provider references. They also make the system easier to teach. Humans naturally classify tasks by intention, not by model SKU.

This design compares favorably with both naive auto-routing and pure manual model selection. Naive auto-routing hides too much and can feel magical or arbitrary. Pure manual selection exposes too much backend detail and causes configuration sprawl. OMO’s semantic categories sit between those extremes. They expose meaningful control while preserving backend flexibility.

There is also an economic dimension. Category routing allows the system to reserve expensive models for high-value work. If every task defaults to a frontier reasoning model, the agent becomes powerful but financially irrational. If every task defaults to a cheap model, quality collapses. Categories create a middle path: cheap where cheap is enough, expensive where expensive is justified.

Ultimately, the semantic category system is a sign of maturity. It treats model selection as infrastructure, not user interface. More importantly, it recognizes that the enduring abstraction in coding agents is not the model name but the work intent. That is a lesson many future agent systems will likely copy.