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

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.