Orch: agentes de código en paralelo sin quedarte sin cuota

Por qué hice Orch: correr varios agentes de IA a la vez sin agotar la cuota del proveedor, y que el cliente vea el avance sin preguntar.

5 min de lectura

Compartir WhatsAppLinkedInX
Ilustración isométrica de un grafo de tareas que reparte trabajo a varias terminales, con un medidor de consumo y un panel de avance

Un agente de código ya ayuda bastante trabajando solo. El problema es que, cuando el proyecto tiene muchas tareas que no dependen entre sí, esperar a que termine una para lanzar la siguiente es perder tiempo. Lo que uno hace entonces es abrir varias terminales y poner un agente en cada una, y ahí empiezan los problemas.

La cuota se acaba a mitad del trabajo

Anthropic, OpenAI y Google limitan cuánto puedes usar en una ventana de tiempo. Con un agente casi nunca llegas al límite; con cuatro corriendo contra el mismo proveedor llegas rápido. Cuando pasa, el proveedor te bloquea, los agentes se cortan a medias y tu propia terminal queda sin servicio hasta que se renueva la ventana.

Los que no programan quieren saber cómo va

Casi todo proyecto tiene stakeholders que no programan y necesitan ver que avanza: el cliente, un socio, el gerente que lo paga. Si no tienes una forma de mostrárselo, terminas escribiendo mensajes de estado en lugar de trabajar, o ellos se quedan con la duda. Por eso diseñé Orch pensando en esas personas tanto como en quien escribe el código.

Qué hace Orch

Orch es una herramienta de línea de comandos para estos dos problemas. Escribes el trabajo como un documento con fases y tareas, y Orch lo convierte en una lista donde cada tarea sabe de cuáles depende. Luego corre en paralelo las que ya pueden empezar, cada una con el agente que le asignes: Claude Code, Codex, OpenCode, Gemini o Antigravity.

Con OpenCode además puedes usar modelos de otros proveedores, por ejemplo a través de OpenRouter, o uno que corra en tu propia máquina. Así repartes el trabajo: las tareas difíciles a un modelo más caro, las mecánicas a uno barato, y no dependes de la cuota de un solo proveedor.

Cada tarea trabaja en su propia copia del repositorio y en su propia rama, y cuando termina abre un pull request. Los agentes no se pisan y puedes revisar cada cambio por separado.

Con la cuota, Orch lleva la cuenta de lo que consumió cada proveedor en su ventana. Cuando se acerca al límite, deja de mandarle tareas nuevas y espera a que la ventana se renueve, así que el bloqueo no llega a ocurrir.

El freno que no frenaba

La primera versión de ese freno tenía un error que tardé en ver: nunca se activaba. Claude Code informa por separado los tokens que lee normalmente y los que saca de su caché, y Orch solo sumaba los primeros. En una tarea real que revisé, Claude reportó 19 tokens normales y más de 60.000 desde la caché. Con esa cuenta, Orch creía que en una ventana de cinco horas cabían unas 770 tareas, así que nunca frenaba y el bloqueo del proveedor llegaba igual.

Lo corregí en la versión 0.15, en septiembre. Ahora la caché cuenta según lo que Anthropic cobra por ella: leer de la caché vale un 10 % de un token normal y escribir en ella, un 125 %. Con la misma tarea, el freno se activa después de unas 16, que es lo que buscaba el ajuste por defecto: dejarte cuota libre para seguir usando el agente a mano mientras Orch trabaja.

El panel de quien opera

Mientras las tareas corren, Orch abre un panel en el navegador para quien está operando. Ahí ves qué está haciendo cada agente, el grafo de dependencias, cuánto consumió cada proveedor de su ventana y el camino de cada tarea hasta el pull request.

Grafo de dependencias del proyecto fluent en el panel de Orch: 16 tareas en cinco fases, 15 terminadas y una bloqueada en naranja

Ese es el grafo de fluent, un proyecto mío que hice completo con Orch: 16 tareas en cinco fases. Quince ya terminaron. La naranja quedó frenada a propósito, porque llama a un servicio que gasta la cuota gratuita de otros proveedores, así que la marqué para que solo corra cuando yo la autorice. Orch no la despacha y la deja en “Necesita tu atención” hasta que alguien la desbloquee.

El panel de ese proyecto está abierto en fluent-ops.knaimero.app si quieres mirarlo por dentro.

Una página para los stakeholders

El cliente, o quien tenga que seguir el proyecto, recibe un link a una página que se actualiza sola:

Página del cliente del proyecto fluent en Orch: frase de estado, 15 de 16 entregas, un ítem en espera con su motivo, la etapa actual y cómo se verificó cada entrega

Arriba, una frase dice en qué punto está el trabajo y cuánto ya se entregó. Debajo aparece lo que está detenido y por qué, la etapa en curso, lo que se entregó en la semana y cómo se verificó cada entrega: pruebas automáticas, revisión del estilo del código y build completo. La página sale en el idioma del proyecto; la de fluent está en portugués.

Ese resumen lo arma Orch con los datos del proyecto cada vez que se abre la página, sin llamar a ningún modelo de IA. No cuesta nada y, con los mismos datos, dice siempre lo mismo. El cliente no ve logs ni código, y el gasto en IA solo aparece si tú lo activas. La página de fluent está en fluent-orch.knaimero.app.

Cómo se usa

orch atomize --apply   # del documento a la lista de tareas
orch run               # corre las tareas en paralelo con los agentes
orch publish           # genera la página para el cliente

Corre en tu máquina, con los agentes y las claves que ya tienes. Es un solo programa escrito en Go, sin servidor que mantener, y nunca guarda una clave de modelo.

Otras opciones

Hay otras herramientas open source para coordinar agentes de código, más grandes y con más funciones, como Multica, Vibe Kanban o Claude Squad. Si lo que necesitas es frenar el consumo por proveedor o mostrarle el avance a un cliente, eso es lo que Orch hace y ellas no.

Puedes probarlo en el navegador sin instalar nada o ver el código en GitHub. Saco una versión por semana y en cada una cuento qué cambió y qué se rompió.