Delegating to OpenCode models

The opencode MCP server runs tasks with opencode run in the user's project. The delegated model has its own tools (read, edit, shell), so it can implement code, not just answer. You stay the orchestrator: you plan, write the brief, and review what comes back.

Tools

In a plugin install the tools are named like mcp__plugin_opencode-delegate_opencode__delegate. With a manual install they are mcp__opencode__delegate.

Picking the model

• Pass what the user said: model: "grok 4.7", "kimi k3", "xai grok 4.7". The server matches loose names. If a model is offered by several providers, the model maker's own provider wins over resellers like opencode-go, so "grok 4.7" goes to xai/grok-4.7. A provider word in the name overrides this ("opencode-go grok 4.7" → opencode-go/…). Include the provider word only when the user names one.
• If you get an ambiguous error, the name matched several different models. Choose from the candidates it lists, and ask the user only if their intent is unclear.
• For a reasoning variant, add #variant, e.g. "xai/grok-4.7#high".
• If the user names no model, omit model. Tasks that edit files get the default (opencode-go/muse-spark-1.3-contributor). Read-only tasks with auto: false get the free opencode/muse-spark-1.3-contributor-free. Use auto: false for reading or summarising files, answering questions about code, and reviews.

Writing the brief (prompt)

The delegated model cannot see this conversation. Write a self-contained brief:

1. Goal: what to build or fix, and why.
2. Context: the relevant files and paths, the existing patterns to follow, and the commands to build and test.
3. Constraints: what not to touch, and the style to follow. Tell it not to commit unless you want a commit.
4. Done when: the acceptance criteria, e.g. "bun test passes" or "prints X".
5. Report: ask for a short summary of the changes and anything left undone.

Use files to attach key files. Keep cwd at the project root unless the task is scoped to a subdirectory.

Permissions

auto defaults to true. The model can edit files and run commands without asking, but opencode rules set to "deny" are still enforced. Pass auto: false for read-only work, such as a review, a second opinion or a question.

After it returns: review, don't trust blindly

The result reports status, session_id, token usage, the tools used, and git changes.

1. Read the diff (git diff) for the files it lists.
2. Run the tests or build yourself.
3. To fix something, either continue the same session with delegate and session_id, giving precise feedback, or fix it yourself if that's quicker.
4. Tell the user which model did what, and your verdict on it.

Parallel and multi-model patterns

• Fan out: call delegate_async once per model or subtask, then task_result with wait_s for each. Parallel tasks that edit files must use separate git worktrees (git worktree add) or non-overlapping files, because they share the directory.
• Compare: give the same brief to 2–3 models in separate worktrees, then diff the results and pick or merge the best one.
• Second opinion: auto: false with a prompt like "review this diff for bugs: …".
• Subagents / workflows: the opencode-worker agent wraps this loop. Spawn it with the model and task in its prompt, e.g. "Use opencode model kimi k3 to add tests for src/foo.ts".