You have read the README. You have installed the plugin. You have probably had at least one billing surprise. Now you want to understand whether this architecture is sound or whether you are paying a complexity premium for marginal gains.
This post is for engineers who ship production software and want to evaluate oh-my-opencode as infrastructure, not as a product demo.
The Architecture: Four Layers Worth Understanding
The OpenCode Book documents oh-my-opencode as a "framework-level" plugin with a four-layer architecture. That description is accurate, and the layers matter because they explain where the token overhead comes from.
Layer 1: Plugin Interface. This is the translation layer. It takes oh-my-opencode's internal capabilities and exposes them as OpenCode-compatible hooks. It implements chat.params, chat.message, event, tool.execute.before, and tool.execute.after. The plugin interface is where context gets injected. Every prompt passes through here, and every prompt picks up the agent definitions, tool schemas, and rule files. This layer is the primary source of the 15K-25K token overhead you see on simple prompts.
Layer 2: Capability Layer. This is the meat. Agents, tools, hooks, features, and MCP servers all live here. The codebase spans tens of thousands of lines. Eleven agent definitions, fifteen custom tools, fifty-three hooks, twenty feature modules, and three embedded MCP services. Each agent has its own prompt template, tool permissions, and model routing logic. The capability layer is well-organized but heavy. There is no deferred loading. Every agent definition is in context on every prompt, even if only one agent is active.
Layer 3: Infrastructure. Configuration management, provider authentication, session storage, and telemetry. The config system supports JSONC with comments and trailing commas. Config files are walked up from the project directory to $HOME, closest wins. Legacy oh-my-opencode.json basenames are still recognized during the rename transition.
Layer 4: OpenCode Runtime. This is not oh-my-opencode code. It is the foundation. The @opencode-ai/plugin package defines the contract, and OpenCode's loader discovers and invokes the plugin.
The initialization follows a staged pattern: createManagers() -> createTools() -> createHooks() -> createPluginInterface(). Each stage's output feeds the next. This is clean dependency injection, but it means every capability is eagerly loaded at startup. There is no lazy loading of agent definitions or tool schemas.
The Economics of Per-Agent Model Routing
Oh-my-opencode's most opinionated design decision is per-agent model routing with fallback chains. This is not a convenience feature. It is a cost structure.
Here is the default routing for the agents you are most likely to use:
| Agent | Primary Model | Fallback Chain | Typical Task Duration |
| --- | --- | --- | --- |
| Sisyphus | Claude Opus 4.7 | Kimi K2.6, GLM-5.1 | 30-120s |
| Hephaestus | GPT-5.5 | GPT-5.2, GPT-5.4 | 60-300s |
| Oracle | GPT-5.2 Medium | Claude Sonnet 4.6 | 45-180s |
| Librarian | Claude Sonnet 4.5 | Claude Haiku 3.5 | 20-90s |
| Explore | Grok Code Fast | Local Qwen2.5-Coder | 10-45s |The cost implication is immediate. A single ultrawork task that spawns five agents in parallel can consume tokens from five different providers simultaneously. You are not just paying for one model. You are paying for the orchestration overhead plus the specialist compute.
I modeled the cost of a typical medium-complexity task across three configurations:
Configuration A: Vanilla OpenCode with Claude Sonnet 4.6
- Single agent, single model
- ~8,000 input tokens, ~4,000 output tokens
- Cost: ~$0.42
- Time: ~3 minutes
Configuration B: Oh-my-opencode with default routing, `max_concurrent_tasks: 2`
- Sisyphus (planning) + Hephaestus (implementation) + Oracle (review)
- ~42,000 input tokens (including context injection), ~18,000 output tokens
- Cost: ~$2.10
- Time: ~8 minutes
Configuration C: Oh-my-opencode with default routing, `max_concurrent_tasks: 5`
- Full parallel team
- ~67,000 input tokens, ~31,000 output tokens
- Cost: ~$3.80
- Time: ~12 minutes (slower due to rate limit retries)
The numbers are approximate and depend on your provider pricing. But the ratio is consistent. Oh-my-opencode costs 4-9x more per task than vanilla OpenCode. The question is whether the output quality or time savings justify the multiplier.
For a 45,000-line Tauri-to-SaaS conversion that would take a human three days, paying $4 instead of $0.40 is trivial. For a ten-line bug fix, it is absurd.
Where the Orchestration Adds Value
Multi-agent orchestration is not always better. It is better for a specific class of problem.
The plugin adds genuine value when these conditions are met:
- Task decomposition is non-obvious. The subtasks are not trivially sequential. Research can happen while implementation starts. Tests can be written while the planner refines the approach. Parallelism is real, not simulated.
- Verification is expensive. Oracle's read-only advisory role means you can get architecture feedback without risking accidental edits. In vanilla OpenCode, you might ask "what do you think of this approach?" and the agent starts changing files before you finish the sentence.
- Context gathering is the bottleneck. The Librarian and Explore agents search docs and codebases in parallel while Hephaestus works. In a single-agent workflow, the agent stops working to search, then resumes. The parallelism here is not cosmetic. It saves wall-clock time.
- The task has clear acceptance criteria. Prometheus builds a plan with verifiable milestones. Sisyphus checks completion against those milestones. This works when you know what "done" looks like. It fails when the task is exploratory.
The 8000 ESLint warnings cleared in a day is a perfect example. Parallel Explore agents scanned the codebase while worker agents executed fixes. The task was large, repetitive, and had clear success criteria. That is where orchestration wins.
Where the Orchestration Is a Tax
Here are the cases where oh-my-opencode adds cost and latency without improving outcomes.
Single-context reasoning tasks. A coding evaluation with self-contained problems showed vanilla OpenCode at 73.1% pass rate versus OMO at 69.2%. OMO made 96 requests versus 27 and took 55 minutes versus 45. There was no parallelism to exploit. No specialist knowledge to pull in. The orchestration layer added overhead without adding value.
Budget model workflows. If you are running Qwen2.5-Coder-7B locally, the orchestration complexity degrades output. Sisyphus needs a Claude-class model for reliable delegation. Hephaestus needs GPT-5.5 for deep reasoning. Running these on smaller models produces truncation errors and poor task decomposition.
Tasks with implicit sequential dependencies. If step B cannot start until step A produces a specific output, parallel agents just wait. You pay for context windows that are mostly idle.
Exploratory work without clear acceptance criteria. Prometheus cannot build a plan for "figure out what our users actually want." The interview mode asks good questions, but it cannot manufacture clarity from ambiguity.
The Context7 and OpenViking Integration: Deeper Than It Looks
The ticket author mentioned combining oh-my-opencode with Context7 and OpenViking. This is not just tool stacking. The three tools solve different parts of the context problem.
Context7 solves recency. It gives your agents current documentation. When GPT-5.5's training cutoff is six months old and your team upgraded to Next.js 15 last week, Context7 closes the gap. The MCP resolves library IDs, fetches version-specific snippets, and injects them into the prompt. The Librarian agent uses this automatically when it detects a framework mention.
OpenViking solves structure. Traditional RAG stores context as flat text chunks. OpenViking organizes it as a virtual filesystem with a viking:// protocol. Memories, resources, and skills get URIs. Agents browse directories instead of searching vectors.
The L0/L1/L2 tiered loading is the architectural insight. L0 is the abstract path. "You need the auth module." L1 adds the module overview. "The auth module handles OAuth2 and JWT." L2 loads the implementation details only when the agent asks. This is a deliberate inversion of the typical "dump everything into context" approach.
On the LoCoMo long-conversation benchmark, OpenViking improved OpenClaw accuracy from 24.20% to 82.08% while cutting input tokens from 392 million to 37 million. For Claude Code, it improved accuracy from 57.21% to 80.32% while cutting tokens from 353 million to 130 million. Those are not marginal gains. They are qualitative improvements that come from structural context organization, not better embeddings.
The practical integration is straightforward. OpenViking runs as an HTTP server. Oh-my-opencode registers it as an MCP. The agent calls ov find and ov tree instead of vector searches. You get directory-aware retrieval with visualized trajectories.
The Billing Risks: A Post-Mortem
The March 2026 billing incident deserves analysis because it reveals systemic weaknesses in the orchestration layer.
A user running a routine task was billed ~$438 in a single afternoon. Three failures compounded:
- No circuit breaker. Subagents had no maximum step limit. A Gemini model delegated to a visual-engineering task got stuck in a git diff / read verification loop. It ran 809 consecutive turns over 3.5 hours. The parent agent never intervened.
- Silent model routing. The user's session was configured for GPT-5.4. But category routing sent the delegated task to Gemini 3.1 Pro. The user had no visibility into this until they inspected the SQLite task log after the fact.
- Incorrect cost display. OpenCode's pricing snapshot for Gemini 3.1 Pro did not include the 200K+ context multiplier. Google charges 2x for contexts over 200K tokens. The displayed cost was less than half the actual bill.
PR #2590 addresses the circuit breaker with a configurable max step limit and loop detection. But the other two issues, silent routing and incorrect cost display, are harder fixes. They touch on provider transparency and plugin trust boundaries.
The lesson is not "do not use Gemini." The lesson is that multi-provider orchestration introduces trust boundaries that single-provider workflows do not. When you delegate to an agent, you are delegating budget authority too. Until there is a hard cap on per-task spend, this risk persists.
When Not to Use Oh My Opencode
I will state this plainly. There are teams for whom this plugin is the wrong choice.
Do not use it if:
- Your tasks are mostly single-file edits and quick fixes. The context injection overhead is a pure tax.
- You do not have budget transparency across providers. If you cannot answer "what did I spend yesterday?" you will get surprised.
- Your team lacks the operational maturity to monitor agent behavior. The plugin requires active supervision, not fire-and-forget usage.
- You are running entirely on local models below 13B parameters. The orchestrator needs reasoning capacity that small models cannot reliably provide.
- You need deterministic, reproducible builds. Agent outputs vary by model version, provider latency, and context window state. This is not a CI tool.
A Note on the Anthropic Claim
The project README states, "Anthropic blocked OpenCode because of us." It links to a tweet by thdxr. The tweet claims Anthropic restricted OpenCode's access to Claude models because oh-my-opencode was competing with Claude Code.
I cannot verify this claim independently. Anthropic has never publicly confirmed or denied it. The restriction may have been for unrelated terms-of-service reasons. What matters for your decision is this: if you depend on Claude models, you need an Anthropic API key. Whether the restriction was competitive or contractual does not change your cost structure.
The Honest Verdict
Oh-my-opencode is a genuine engineering achievement. It demonstrates that OpenCode's plugin system can support framework-level extensions. The per-agent model routing, hash-anchored edits, and parallel execution are real innovations that solve real problems.
It is also a complex, expensive, and occasionally dangerous tool. The token overhead is not a bug. It is the cost of keeping eleven agent definitions and fifty-three hooks in context. The billing risks are not edge cases. They are systemic consequences of delegating budget authority to subagents without hard caps.
Use it when your tasks are large enough that 4-9x cost multiplier is irrelevant compared to human time saved. Do not use it when your tasks are small enough that the overhead dominates.
The plugin's value proposition is straightforward. It turns OpenCode from a single assistant into a coordinated team. Teams are powerful. They are also expensive to run. Make sure your problems are worth the payroll.