Stop Paying Premium-Model Prices for Grunt Work

Your orchestrator model is brilliant. It's also doing work an intern could handle. Every time Claude...

Your orchestrator model is brilliant. It's also doing work an intern could handle.

Every time Claude Code renames a variable, writes boilerplate tests, or greps through a codebase, you're paying Opus-tier (or Fable-tier) prices for a task a cheaper model would do just as well. Worse: while your top model is busy running that grunt work, it isn't doing the thing you actually hired it for — thinking about your architecture, your bug, your feature.

The fix isn't a smarter prompt. It's a division of labor: the expensive model directs, cheaper models execute. The orchestrator breaks the problem down, delegates the mechanical pieces, reviews the results, and keeps its context — and your budget — focused on the hard parts.

That's exactly what opencode-mcp does.

The idea in one sentence

opencode-mcp is an MCP server that lets any MCP host — Claude Code, Codex, Cursor — drive an OpenCode instance and delegate tasks to its subagents, asynchronously and in parallel.

Your orchestrator stays in charge. OpenCode's agents — running whatever models you've configured, from budget tiers to specialized ones — do the heavy lifting.

Install it in 30 seconds

You need Node.js 18+ and OpenCode installed with at least one provider configured. Then, for Claude Code:

claude mcp add opencode -- npx -y mcp-server-opencode

For Codex:

codex mcp add opencode -- npx -y mcp-server-opencode

That's it. No cloning, no building. Restart your host and the opencode_* tools are available.

A real session: five test suites, in parallel, while Claude keeps working

Here's the demo that convinced me to build this. The prompt to Claude Code:

"Generate unit tests for blocks 1-5. Delegate the work to OpenCode agents and review the results when they're done."

What happens under the hood:

1. Claude starts a server and checks who's available.

Claude calls opencode_start_server, then opencode_list_agents to see which agents and models the OpenCode instance exposes.

2. Claude fires five tasks — and doesn't wait.

Five opencode_start_task calls go out, one per block. Each returns a task_id immediately. Each task runs in its own isolated OpenCode session, so the five agents can't step on each other.

This is the key design decision: delegation is asynchronous. Claude isn't blocked watching a progress bar. While the five subagents write tests, the orchestrator keeps moving — in my session, it used that time to review the service interfaces and draft the integration-test plan itself.

3. Claude waits for all five — with visibility.

When it's ready to collect, Claude calls:

opencode_wait_for_task
  task_ids: [t1, t2, t3, t4, t5]
  mode: "all"
  include_progress: true

wait_for_task long-polls until every task finishes (or a timeout elapses). If something is still running when the timeout hits, include_progress returns a partial output snippet and the tool the subagent is executing right now — so you see "it's running the test suite", not a black box.

4. Claude reviews and iterates.

One of the five suites came back thin — missing edge cases on error paths. Instead of starting over, Claude calls opencode_continue_task on that session: "Add tests for the failure paths in retry()." The subagent picks up right where it left off, full context intact.

Total orchestrator involvement: break down the work, fire, review, refine. The mechanical writing happened elsewhere, on the models you chose for it.

Why async changes everything

Most "delegate to another agent" MCP servers make a blocking tool call: the host calls the tool, the tool runs the agent, and everybody waits. That breaks down fast:

• MCP client timeouts. A 20-minute refactor doesn't fit inside a tool-call timeout. Async delegation sidesteps this entirely: start_task responds in milliseconds, and status is polled separately.
• No parallelism. Blocking calls serialize your subagents. With fire-and-forget tasks, five agents genuinely run at once, each in an isolated session.
• No visibility. A blocking call is silent until it returns. get_task_status and wait_for_task with include_progress show partial output and the currently running tool mid-flight.
• No conversation. When a blocking call returns, the session is gone. Here, continue_task keeps the subagent's session alive for iterative back-and-forth — you refine the result instead of re-running the task.

One more piece worth highlighting: the server ships a delegate_task MCP prompt that includes a model selection guide — a mapping from each OpenCode model tier to the task difficulty it should handle. The point of delegation isn't just being able to hand off work; it's knowing what to hand off to whom. The prompt teaches your orchestrator exactly that.

The tool surface

Nine focused tools — servers, agents, and the task lifecycle:

That's deliberate. This server doesn't try to wrap every OpenCode capability behind seventy tools — it does one thing: async task delegation, done properly. The codebase backs that up with a 100% coverage threshold enforced in CI (lines, branches, functions, and statements — any uncovered line breaks the build).

Beyond the fan-out

The demo covered the parallel-tasks case, but the same pattern works for more:

• Cost-tiering: route mechanical work (renames, boilerplate, docs) to budget models and save the premium one for decisions.
• Cross-model second opinions: have a different model review your orchestrator's diff.
• Long-running background work: kick off a 20-minute refactor and keep working while it runs.

Try it

claude mcp add opencode -- npx -y mcp-server-opencode

The repo is at github.com/alejandro-technology/opencode-mcp and the package is mcp-server-opencode on npm. Install it, delegate something, and tell me what you handed off — I want to hear what your orchestrator stopped doing itself.