oh-my-opencode-slim: a seven-agent orchestration plugin for OpenCode

The problem: one model doing seven jobs badly

A single coding agent has to search a codebase, read documentation, reason about architecture, write UI code and then implement the change, all with the same context window and the same per-token price. oh-my-opencode-slim takes the position that those are different jobs and should not share a model. The README describes the plugin as an agent orchestration plugin for OpenCode with a built-in team of specialized agents that can scout a codebase, look up fresh documentation, review architecture, handle UI work, and execute well-scoped implementation tasks under one orchestrator. The stated goal is balancing quality, speed and cost by routing each part of the job to the agent best suited for it. That framing is the whole product. If you are happy with one frontier model handling everything, this plugin adds configuration surface without adding capability. It is aimed at people who already run OpenCode, already pay for more than one provider, and want the cheap parts of the work to run on cheap models.

Seven agents, one orchestrator, and how work actually flows

The team is named in the README: Orchestrator, Explorer, Oracle, Council, Librarian, Designer, and Fixer. The Orchestrator plans the work graph, dispatches specialists as background tasks, and reconciles their results before continuing. That last clause is the mechanism worth understanding. Specialists do not run inline and block the parent; they run as background tasks, and the parent is woken by terminal results, with reopen corrections keeping idle parents current. The README points readers at the Orchestrator prompt in src/agents/orchestrator.ts for the scheduler rules, specialist routing logic, and thresholds for when work should be assigned to background agents. Those thresholds are not documented in the README itself, which means the practical behaviour of auto-delegation is defined in source rather than in prose. You can also bypass the scheduler entirely and call a subagent directly with @agentName <task>. Two features sit alongside the core loop. Council runs multiple models in parallel on the same question and synthesizes a single answer, invoked with @council. Preset switching swaps the whole team's models at runtime with /preset, and the README notes single-parent preset inheritance. Bundled skills such as deepwork, codemap, verification-planning and reflect are prompt-based workflows assigned per agent.

Installing oh-my-opencode-slim and running a first delegation

The README gives a manual install path through the published CLI, which it describes as a Node-compatible bundle. With Bun installed, the command is a single bunx invocation; npx works as an alternative if Bun is not present. The installer generates both OpenAI and OpenCode Go presets, with OpenAI active by default, and writes configuration the plugin reads at startup. To make the OpenCode Go preset active during install, pass --preset=opencode-go, or change the default preset name in the config file afterwards. After installing, log in to the providers you intend to use and refresh the model list so OpenCode can see them. Then open ~/.config/opencode/oh-my-opencode-slim.json and set the model for each agent. The README is explicit that the defaults are only a starting point and that tuning models and agents for your own workflow is expected. There is no documented uninstall command, which is worth knowing before you start: the installer's main side effect is an entry in the plugin array of ~/.config/opencode/opencode.json, and removing that entry is the visible part of backing the change out. The README does not document a rollback procedure.

bunx oh-my-opencode-slim@latest install

If Bun is not installed, the README notes the published CLI is a Node-compatible bundle, so npx works instead.

npx oh-my-opencode-slim@latest install

To make the OpenCode Go preset active during install, pass the preset flag; otherwise OpenAI stays active by default.

bunx oh-my-opencode-slim@latest install --preset=opencode-go

Then log in to the providers you want and refresh the model list so OpenCode can see them.

opencode auth login
opencode models --refresh

Running from master when the release lags

The README offers a separate path for people who want the latest code, easier bug fixes, or a local setup for development and contributions. It clones the repository into ~/repos/oh-my-opencode-slim, installs dependencies with Bun, builds, and then runs the CLI from the built dist directory rather than from the registry. The installer adds the local repo path to the plugin array in ~/.config/opencode/opencode.json, so OpenCode loads the plugin from that folder instead of from a published package. Updating is a git pull followed by bun install and bun run build. This is the path to take if you intend to read the Orchestrator prompt and adjust delegation thresholds, because you are working against a source checkout rather than a compiled artifact. It also means you own the build step: if the build breaks on your machine, you have no plugin, and there is no documented fallback to the published version short of reinstalling it.

git clone https://github.com/alvinunreal/oh-my-opencode-slim.git ~/repos/oh-my-opencode-slim
cd ~/repos/oh-my-opencode-slim
bun install
bun run build
bun dist/cli/index.js install

Updating a master checkout is three commands, and the README does not describe a rollback if one of them fails.

cd ~/repos/oh-my-opencode-slim
git pull
bun install
bun run build

Where the plugin stops being the right tool

The strongest limitation is structural: this is a plugin for OpenCode, not a standalone tool. The package description calls it a lightweight agent orchestration plugin for OpenCode and a slimmed-down fork of oh-my-opencode. If you do not use OpenCode, none of the seven agents are reachable, and the repository layout confirms the coupling: the build marks @opencode-ai/plugin as an external dependency, and the installer edits OpenCode's own config file. A second limitation is that background orchestration is now the default workflow, and the README recommends understanding how it works before relying on it. Parallel specialists consume tokens in parallel. The README recommends enabling multiplexer integration, which opens each agent in a dedicated Tmux, Zellij, Herdr, cmux, or kitty pane, precisely because otherwise you cannot see what the background agents are doing. That is an admission that the default experience is opaque without extra tooling. A third point: the routing thresholds live in source, not in documentation, so behaviour can shift between releases without a corresponding documentation change. The release cadence supports that concern. Three patch releases landed within five days in September 2026, and the last push to master was on 2026-09-21.

oh-my-opencode-slim versus the parent project and single-agent setups

The most direct alternative is oh-my-opencode, the project this one is forked from. The package description is unambiguous: oh-my-opencode-slim is a slimmed-down fork. The difference is scope rather than philosophy. Both orchestrate agents for OpenCode; the slim variant trims the surface and adds its own features, with Council, the Companion desktop window, and preset switching called out in the README. If you already run the parent and depend on its full feature set, switching means checking whether the trimmed pieces are ones you use. The other alternative is not a competing plugin at all: it is running OpenCode with a single model and no orchestration layer. That setup has no config file to maintain, no scheduler thresholds to reason about, and no risk of parallel background agents spending your budget while you are not watching. It gives up per-task model routing, which is the only reason to install this. A third option is a general agent framework where you write the routing yourself. That gives you exact control over which model handles which step, at the cost of building and maintaining the dispatch logic that oh-my-opencode-slim ships as a default.

Maintenance cost, licensing and what the release history implies

The repository is not archived, and the last push was on 2026-09-21, so this is live code rather than an abandoned experiment. The version in package.json is 2.2.22, matching the most recent release, and the three releases in the days before it were all patch-level. That pattern suggests active bug fixing rather than feature churn, but it also means you should expect to reinstall or rebuild reasonably often if you track releases. Running from master shifts that cost onto you: every update is a git pull, bun install and bun run build. The project is MIT licensed, which is permissive and places few obligations on how you use or redistribute it. That is a statement about the licence text, not advice about your situation; if you are embedding the plugin in something commercial, read the LICENSE file in the repository root and decide for yourself. Two documentation gaps are worth flagging. The README does not document an uninstall command, and it does not describe a rollback path if a new release breaks your setup. For a plugin whose installer edits a shared OpenCode config file, both are real omissions.

Editorial conclusion

Adopt oh-my-opencode-slim if you already use OpenCode and hold credentials for more than one model provider, because the whole point is routing each agent to a different model and the defaults only make sense with that mix. Skip it if you want a single-model coding assistant or do not want to maintain a JSON config and a multiplexer setup. Before committing, verify three things: that the installer wrote the plugin entry into ~/.config/opencode/opencode.json, that the model names in ~/.config/opencode/oh-my-opencode-slim.json actually resolve after opencode models --refresh, and that the Orchestrator prompt's background thresholds match how much you are willing to spend on parallel specialists.

Frequently asked questions

Official sources

1. alvinunreal/oh-my-opencode-slim on GitHub
2. License: MIT
3. Project website
4. README
5. Releases