Escritura tecnica del proyecto initech.
1 de abril de 2026
Claude Code, Codex y OpenCode en el mismo TUI
initech empezo con una suposicion simple: cada panel era Claude Code.
Esa suposicion deja de servir en cuanto mezclas CLIs de agentes de verdad. Claude Code para un refactor grande. Codex en full-auto para una tarea contenida. OpenCode para otro estilo de trabajo. El problema no es lanzarlos. El problema es supervisarlos juntos sin convertir la pantalla en una pila de pestañas sueltas.
Ahora initech puede ejecutar Claude Code, OpenAI Codex y OpenCode lado a lado en el mismo TUI.
Muchas herramientas multi-agent asumen en silencio que todos los paneles ejecutan el mismo binario. Esa suposicion se filtra en el arranque, en la inyeccion de texto, en la deteccion del prompt y en la tecla que realmente envia el mensaje.
Cuando mezclas herramientas aparecen los bordes. Un CLI espera bracketed paste. Otro lo interpreta mal. Un agente esta listo en un > simple. Otro sigue arrancando servicios o esperando una pantalla de confianza. Un prompt de permisos puede frenar un rol autonomo hasta que alguien lo vea.
El cambio visible es role_overrides en initech.yaml. Los roles que se salen del comando global pueden definir su propio array de comando, y agent_type le dice al runtime como manejar ese panel.
project: myproject
root: ~/src/myproject
claude_command: ["claude"]
claude_args: ["--continue"]
roles:
- super
- eng1
- eng2
- qa1
role_overrides:
eng2:
command: ["codex", "resume", "--last", "--full-auto"]
agent_type: codex
qa1:
command: ["opencode", "--continue"]
agent_type: opencode
command reemplaza por completo el comando global. No se agregan flags de Claude por accidente. Y agent_type no es decoracion: selecciona la ruta de envio, la deteccion de readiness, la tecla de submit y cualquier automatizacion especifica del CLI.
El problema aburrido en un multiplexor de terminal es submit. Si submit falla, el resto no importa.
Claude Code mantiene la ruta de bracketed paste. Los paneles tipo Codex esperan a que el prompt este realmente listo, escriben el cuerpo directo al PTY, dejan pasar el detector de paste burst y solo entonces envian la tecla de submit.
Codex tiene otro problema en corridas autonomas: los prompts de permisos. Uno solo puede dejar un rol bloqueado hasta que un humano vuelva a mirar la terminal.
Para agent_type: codex, initech activa auto_approve por defecto. El panel detecta patrones conocidos de prompts de permiso en la parte baja del terminal y envia p para aprobar y recordar la decision.
La parte interesante no es "ahora tambien lanza Codex". La parte interesante es que initech se esta moviendo hacia un multiplexor de terminal agnostico al agente.
Una sola interfaz para el operador. Un solo TUI. Un solo lugar para supervisar trabajo. Dentro de cada panel, usa el agente que mejor encaja con el rol.
Instalacion: initech.sh/install.sh
Codigo fuente: github.com/nmelo/initech
31 de marzo de 2026
Overrides de comando por rol: ejecuta Codex, Amp y Claude Code en paralelo
initech ya no es exclusivo de Claude Code. Con role_overrides en initech.yaml, cualquier rol puede ejecutar un CLI diferente. Codex para un agente, Amp para otro, Claude Code para el resto. El mismo IPC, la misma deteccion de actividad, el mismo TUI.
Un nuevo bloque role_overrides en initech.yaml permite sobreescribir el comando predeterminado por rol:
# initech.yaml role_overrides: codex-eng: command: ['codex', '--full-auto', '--no-alt-screen'] amp-design: command: ['amp']
Cada override mapea un nombre de rol a un array de comandos. El rol sigue teniendo su propio PTY, su propio panel en el TUI, y acceso completo a initech send / initech peek. Al runtime no le importa que hay dentro del PTY.
El concepto de "agent runtime" era aspiracional hasta ahora. initech asumia Claude Code en todos lados: la deteccion de actividad dependia del spinner de Claude, el sistema de eventos parseaba los logs JSONL de Claude, las plantillas de roles eran archivos CLAUDE.md.
Con los overrides de comando, las primitivas centrales siguen funcionando. El flujo de bytes del PTY detecta actividad sin importar que CLI produce la salida. La mensajeria IPC opera a nivel de terminal, no es especifica de Claude. Las plantillas CLAUDE.md solo aplican a roles que ejecutan Claude Code; otros CLIs traen su propia configuracion.
Lo que se pierde con CLIs que no son Claude: el parseo de eventos basado en JSONL (deteccion de finalizacion de beads, deteccion de estancamiento) y las notificaciones toast basadas en logs de sesion. La deteccion de actividad y el IPC siguen funcionando. Para flotas mixtas, los agentes con Claude Code obtienen el conjunto completo de funciones; los demas obtienen gestion confiable de PTY y mensajeria.
El obvio: quieres comparar CLIs de agentes en el mismo codebase. Ejecuta un rol de ingeniero con Claude Code y un rol paralelo con Codex. Misma tarea, diferentes agentes, visibles lado a lado.
El practico: algunas tareas se adaptan mejor a diferentes herramientas. Un agente Codex en modo full-auto para refactors simples. Claude Code para cambios complejos de multiples archivos que necesitan mas guia. Ambos visibles y direccionables desde un solo terminal.
$ curl -fsSL https://initech.sh/install.sh | bash
Codigo fuente y guia del operador: github.com/nmelo/initech
30 de marzo de 2026
Coordinación entre máquinas: ejecuta tu flota de agentes en múltiples máquinas
initech ahora soporta coordinación entre máquinas. Ejecuta initech serve en cualquier máquina — una estación de trabajo, un servidor GPU remoto, una VM en la nube — y el TUI local transmite todos sus paneles de agentes en vivo. Un terminal. Todos los agentes. Cualquier máquina.
Agrega mode: headless, peer_name, listen y token al initech.yaml de la máquina remota:
project: myproject root: /home/user/myproject mode: headless peer_name: workbench listen: ":7391" token: "tu-secreto-compartido" roles: - eng1 - eng2 - eng3
Inicia el daemon:
$ initech serve
Agrega un bloque remotes: al initech.yaml local:
project: myproject
root: /Users/tu/myproject
token: "tu-secreto-compartido"
roles:
- super
- pm
- qa1
remotes:
workbench:
addr: "192.168.1.100:7391"
Lanza el TUI normalmente:
$ initech
$ initech send workbench:eng1 "inicia el refactor de la API" $ initech peek workbench:eng2 -n 30 $ initech peers
28 de marzo de 2026
Por que construimos un multiplexor de terminal para agentes de IA
Construimos un TUI en Go que gestiona multiples agentes de Claude Code ejecutandose en paralelo. Reemplazo a tmux como nuestro runtime de sesion.
Dale a cada agente una terminal ejecutando Claude Code con instrucciones especificas del rol. Un agente supervisor coordina. Los agentes ingenieros implementan. Un agente QA valida. Un agente shipper publica releases. Cada agente recibe un CLAUDE.md que codifica su identidad, restricciones, flujo de trabajo y protocolo de comunicacion.
Ejecutamos esto en cuatro proyectos antes de construir initech. Produjo software real: ingenieria en paralelo, QA independiente, gates de release, memoria institucional entre sesiones.
tmux falla de tres maneras que empeoran a medida que agregas agentes.
tmux send-keys no tiene garantia de entrega. Envias un mensaje al panel de un agente y esperas que llegue. Cuando no llega, no hay error. Un reporte de finalizacion de eng a super se pierde, super no sabe que eng termino, QA nunca se despacha y el bead se estanca por una hora.
Un agente colgado y uno productivo se ven identicos en tmux. Terminado y en medio del trabajo se ven identicos. La unica forma de saberlo es revisar cada panel. Con 9 agentes, son 9 revisiones manuales cada 10-15 minutos.
tmux no sabe que trabajo existe, quien esta asignado a que, o que un agente acaba de marcar una tarea como lista para QA. Toda la orquestacion vive en la ventana de contexto del supervisor. El contexto se compacta. Los mensajes se pierden. El agente supervisor olvida que eng termino. La cadena de despacho se estanca.
tmux es un multiplexor de terminal de proposito general haciendo un trabajo que necesita inteligencia a nivel de aplicacion.
Cada sesion ejecuta un socket de dominio Unix. initech send escribe texto al PTY de un agente a traves del emulador, luego confirma la entrega. El emisor recibe un OK explicito o un error en segundos.
$ initech send eng1 "fix the auth bug in middleware.go" $ initech peek eng1 -n 20
Primero intentamos hacer tail del log de sesion JSONL. No confiable: Claude escribe al JSONL en los limites de conversacion, no de forma predecible. Durante una pausa de pensamiento de 45 segundos, cero entradas. Cualquier timeout es incorrecto para algun valor del timeout.
Lo que funciona: rastrear cuando el PTY produjo salida por ultima vez. El spinner de Claude Code se anima a 10-30 fps durante el pensamiento. El unico estado con cero salida es inactivo-en-prompt. Un umbral de recencia de 2 segundos da una deteccion binaria limpia.
Punto verde significa trabajando. Gris significa inactivo. Amarillo significa inactivo con tareas esperando. La superposicion muestra el estado de cada agente sin abrir ningun panel.
JSONL fallo para deteccion de actividad pero funciona para eventos semanticos. Los logs de sesion contienen resultados de uso de herramientas, mensajes del asistente y secuencias de error. El sistema de eventos los analiza para:
* Finalizacion de bead: el agente ejecuto bd update --status ready_for_qa
* Estancamiento: sin salida por 10+ minutos con un bead asignado
* Bucles de error: 3+ fallos consecutivos de herramientas
* Reclamos de beads: auto-detectados desde comandos bd, sin llamada CLI extra necesaria
Los eventos se muestran como notificaciones toast. "eng1 completed ini-bhk.3" aparece en verde antes de que super lo reporte.
La cinta de cada agente muestra su bead actual. La superposicion muestra el estado de cada agente de un vistazo. Cuando un agente queda inactivo despues de tener un bead, el TUI le dice al agente supervisor directamente: "[from initech] eng1 is now idle (bead: ini-bhk.3). Check if work is complete."
Cada numero de arriba fue producido por la herramienta misma. initech gestiono los agentes que construyeron initech.
El TUI es el runtime. Las plantillas son la inteligencia. Un CLAUDE.md malo produce mala salida sin importar que tan bueno sea el TUI. Reescribimos las 11 plantillas tres veces, cada vez codificando lecciones de fallos reales: agentes ingenieros saltandose comentarios de PLAN, agentes QA aprobando sin revisar, el agente supervisor haciendo trabajo en vez de despachar.
Tres enfoques antes de que la recencia de bytes del PTY funcionara. Tail de JSONL: demasiado lento. Tasa de salida de terminal: falsos positivos de SIGWINCH. Deteccion de prompt: fragil a cambios de UI. El enfoque del spinner solo funciona porque Claude Code siempre produce salida cuando trabaja. Una pantalla estatica de "thinking..." lo romperia.
El fallo numero uno del agente supervisor: hacer implementacion en vez de despachar. Despachar se siente lento. Pero el punto central de multi-agente es la especializacion. "No usar agentes" es ahora el primer modo critico de falla en la plantilla del supervisor.
Cada agente eventualmente olvida comentar PLAN antes de codificar, o hacer push antes de marcar ready_for_qa, o limpiar su display de bead. Auto-notify existe porque los agentes olvidan reportar finalizacion. Los guardrails ayudan pero no eliminan esto. El cumplimiento del proceso es un gradiente, no un binario.
Portabilidad de sesion no se ha iniciado. Mover una sesion entre maquinas (MacBook a workbench) requiere rsync manual. El PRD describe un comando initech migrate que aun no existe.
Gestion de recursos esta detras de un flag. Auto-suspender/reanudar bajo presion de memoria (la funcionalidad que duplicaria la capacidad efectiva de agentes en un laptop de 36GB) esta implementada pero restringida detras de --auto-suspend porque la politica no se ha probado lo suficiente en sesiones reales.
Onboarding es tosco. Un nuevo usuario que ejecuta initech por primera vez ve 7 paneles sin guia. Los tips de la barra de estado rotan en la parte inferior, pero no hay una guia del operador que documente el flujo de trabajo completo. La herramienta fue construida por su propio usuario, y se nota.
Adopcion temprana. initech se ha usado en multiples proyectos, pero la base de usuarios aun es pequena. Mas uso en el mundo real revelara brechas que el dogfooding no encontro.
curl -fsSL https://initech.sh/install.sh | bash mkdir myproject && cd myproject initech init initech
Codigo fuente: github.com/nmelo/initech