DEV Community: Cristian Alejandro

Stop Paying Premium-Model Prices for Grunt Work

Cristian Alejandro — Fri, 17 Jul 2026 22:37:27 +0000

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:

Tool	What it does
`opencode_start_server` / `opencode_stop_server`	Start (or attach to) / stop an OpenCode instance
`opencode_list_agents`	List available agents and models
`opencode_start_task`	Delegate a task; returns a `task_id` immediately
`opencode_continue_task`	Send a follow-up prompt to an existing task's session
`opencode_cancel_task`	Abort a running task
`opencode_get_task_status`	Poll status, optionally with partial progress
`opencode_get_task_result`	Fetch the final result
`opencode_wait_for_task`	Long-poll one or many tasks (`mode: "all"` / `"any"`)

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.

Deja de pagar precios de modelo premium por trabajo mecánico

Cristian Alejandro — Fri, 17 Jul 2026 22:06:34 +0000

Tu modelo orquestador es brillante. Y aun así está haciendo trabajo que podría hacer un becario.

Cada vez que Claude Code renombra una variable, escribe tests de boilerplate o hace grep por el código, estás pagando precios de Opus (o de Fable) por una tarea que un modelo más barato haría igual de bien. Peor aún: mientras tu mejor modelo está ocupado con ese trabajo mecánico, no está haciendo aquello para lo que realmente lo contrataste - pensar en tu arquitectura, tu bug, tu feature.

La solución no es un prompt más inteligente. Es una división del trabajo: el modelo caro dirige, los modelos baratos ejecutan. El orquestador descompone el problema, delega las piezas mecánicas, revisa los resultados y mantiene su contexto - y tu presupuesto - enfocado en las partes difíciles.

Eso es exactamente lo que hace opencode-mcp.

La idea en una frase

opencode-mcp es un servidor MCP que permite a cualquier host MCP — Claude Code, Codex, Cursor — controlar una instancia de OpenCode y delegar tareas a sus subagentes, de forma asíncrona y en paralelo.

Tu orquestador sigue al mando. Los agentes de OpenCode — corriendo los modelos que tengas configurados, desde tiers económicos hasta especializados — hacen el trabajo pesado.

Instálalo en 30 segundos

Necesitas Node.js 18+ y OpenCode instalado con al menos un proveedor configurado. Luego, para Claude Code:

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

Para Codex:

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

Eso es todo. Sin clonar, sin compilar. Reinicia tu host y las herramientas opencode_* quedan disponibles.

Una sesión real: cinco suites de tests, en paralelo, mientras Claude sigue trabajando

Esta es la demo que me convenció de construir esto. El prompt a Claude Code:

"Genera tests unitarios para los bloques 1-5. Delega el trabajo a agentes de OpenCode y revisa los resultados cuando terminen."

Lo que pasa por debajo:

1. Claude levanta un servidor y consulta quién está disponible.

Claude llama a opencode_start_server y luego a opencode_list_agents para ver qué agentes y modelos expone la instancia de OpenCode.

2. Claude dispara cinco tareas — y no espera.

Salen cinco llamadas a opencode_start_task, una por bloque. Cada una devuelve un task_id inmediatamente. Cada tarea corre en su propia sesión aislada de OpenCode, así que los cinco agentes no pueden pisarse entre sí.

Esta es la decisión de diseño clave: la delegación es asíncrona. Claude no queda bloqueado mirando una barra de progreso. Mientras los cinco subagentes escriben tests, el orquestador sigue avanzando — en mi sesión, usó ese tiempo para revisar las interfaces de los servicios y redactar él mismo el plan de tests de integración.

3. Claude espera a los cinco — con visibilidad.

Cuando está listo para recoger resultados, Claude llama a:

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

wait_for_task hace long-polling hasta que todas las tareas terminan (o vence el timeout). Si algo sigue corriendo cuando llega el timeout, include_progress devuelve un fragmento parcial de la salida y la herramienta que el subagente está ejecutando en ese momento — así ves "está corriendo la suite de tests", no una caja negra.

4. Claude revisa e itera.

Una de las cinco suites volvió floja — le faltaban casos borde en las rutas de error. En lugar de empezar de cero, Claude llama a opencode_continue_task sobre esa sesión: "Agrega tests para las rutas de fallo de retry()." El subagente retoma justo donde lo dejó, con todo el contexto intacto.

Participación total del orquestador: descomponer el trabajo, disparar, revisar, refinar. La escritura mecánica ocurrió en otro lado, en los modelos que elegiste para eso.

Por qué lo asíncrono lo cambia todo

La mayoría de los servidores MCP de "delega a otro agente" hacen una llamada bloqueante: el host llama a la herramienta, la herramienta ejecuta al agente, y todos esperan. Eso se rompe rápido:

Timeouts del cliente MCP. Un refactor de 20 minutos no cabe dentro del timeout de una tool call. La delegación asíncrona esquiva el problema por completo: start_task responde en milisegundos y el estado se consulta por separado.
Sin paralelismo. Las llamadas bloqueantes serializan a tus subagentes. Con tareas fire-and-forget, cinco agentes corren genuinamente a la vez, cada uno en una sesión aislada.
Sin visibilidad. Una llamada bloqueante es silenciosa hasta que retorna. get_task_status y wait_for_task con include_progress muestran salida parcial y la herramienta en ejecución a mitad de vuelo.
Sin conversación. Cuando una llamada bloqueante retorna, la sesión desaparece. Aquí, continue_task mantiene viva la sesión del subagente para un ida y vuelta iterativo — refinas el resultado en lugar de relanzar la tarea.

Hay una pieza más que vale la pena destacar: el servidor incluye un prompt MCP llamado delegate_task con una guía de selección de modelo — un mapeo de cada tier de modelo de OpenCode a la dificultad de tarea que debería manejar. El punto de delegar no es solo poder pasar trabajo; es saber qué delegar y a quién. El prompt le enseña exactamente eso a tu orquestador.

La superficie de herramientas

Nueve herramientas enfocadas — servidores, agentes y el ciclo de vida de las tareas:

Herramienta	Qué hace
`opencode_start_server` / `opencode_stop_server`	Inicia (o se conecta a) / detiene una instancia de OpenCode
`opencode_list_agents`	Lista los agentes y modelos disponibles
`opencode_start_task`	Delega una tarea; devuelve un `task_id` inmediatamente
`opencode_continue_task`	Envía un prompt de seguimiento a la sesión de una tarea existente
`opencode_cancel_task`	Aborta una tarea en ejecución
`opencode_get_task_status`	Consulta el estado, opcionalmente con progreso parcial
`opencode_get_task_result`	Obtiene el resultado final
`opencode_wait_for_task`	Long-polling de una o varias tareas (`mode: "all"` / `"any"`)

Este servidor no intenta envolver cada capacidad de OpenCode detrás de setenta herramientas — hace una sola cosa: delegación asíncrona de tareas, bien hecha. El código lo respalda con un umbral de cobertura del 100% aplicado en CI (líneas, ramas, funciones y sentencias — cualquier línea sin cubrir rompe el build).

Más allá del fan-out

La demo cubrió el caso de tareas en paralelo, pero el mismo patrón sirve para más:

Escalonamiento por costo: enruta el trabajo mecánico (renombres, boilerplate, docs) a modelos económicos y reserva el premium para decidir.
Segundas opiniones entre modelos: haz que un modelo distinto revise el diff de tu orquestador.
Trabajo largo en segundo plano: lanza un refactor de 20 minutos y sigue trabajando mientras corre.

Pruébalo

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

El repositorio está en github.com/alejandro-technology/opencode-mcp y el paquete es mcp-server-opencode en npm.