Delegating to OpenCode models

From the main thread, delegate through the opencode-worker agent (spawned in the background) or the /opencode <model> -- <task> slash command, which spawns it. The worker is the only caller of the opencode MCP tools. The delegated model has its own tools (read, edit, shell), so it can implement code, not just answer. You stay the orchestrator: you hand over the task, and you review what comes back.

Mechanism

The opencode MCP server runs opencode run in the project and returns the reply, session id, token usage and git changes. The opencode-worker agent calls its delegate tool, verifies the git changes and tests, iterates at most twice with the same session_id, and reports. The main thread never calls delegate or delegate_async: delegate blocks it, async tasks are lost when the MCP server restarts, and a PreToolUse hook denies the call.

Tools (used by the worker)

In a plugin install the tools are named like mcp__plugin_claudelegate_opencode__delegate. With a manual install they are mcp__opencode__delegate. The worker's prompt must be a self-contained brief (the model cannot see this conversation); pass auto: false for read-only work, session_id to continue.

Modes

Write mode passes --agent build because the project default agent may be plan. --auto approves permissions not explicitly denied; opencode rules set to "deny" are still enforced. In read-only mode, permission requests are rejected rather than approved.

Picking the model

• Pass what the user said: grok 4.7, kimi k3, xai/grok-4.7. The delegate tool resolves a loose name against opencode models and requires an exact version match. If several models match, it returns an ambiguous error with the candidates and the worker picks the best candidate that fits the instructions (a named provider wins); name the exact provider/model when the choice matters.
• For a reasoning variant, add #variant, e.g. xai/grok-4.7#high.
• If the user names no model, omit it. OpenCode then uses its configured default model.

Writing the task

The OpenCode model cannot see this conversation, so the brief must stand on its own. Give:

1. Goal: what to build or fix.
2. Constraints: what not to touch. The agent already tells the model not to commit unless the task says so.
3. Done when: acceptance criteria, e.g. "bun test passes".

Skip pasting file contents and long background; the model looks them up. Run from the project root.

Continuing a session

The agent reports a session id. To give feedback or continue after a timeout, invoke opencode-worker again with that session id and precise feedback.

After it returns: review, don't trust blindly

The worker has already checked the git changes and run the tests; it reports the model used, session id, changed files, its verification and a verdict. Still read the diff.

1. Read the diff (git diff) for the files it lists.
2. Run the tests or build yourself.
3. To fix something, spawn opencode-worker again with the session id and precise feedback.
4. Tell the user which model did what, and your verdict on it.

Parallel and multi-model patterns

• Fan out: spawn separate opencode-worker agents for each model or subtask. 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 task to 2–3 models in separate worktrees, then diff the results and pick or merge the best one.
• Second opinion: read-only mode with a prompt like "review this diff for bugs: …".
• Subagents / workflows: spawn opencode-worker with the model and task in its prompt, e.g. "Use opencode model kimi k3 to add tests for src/foo.ts".