Textos tecnicos do projeto initech.
1 de abril de 2026
Claude Code, Codex e OpenCode na mesma TUI
initech começou com uma suposição simples: todo painel era Claude Code.
Isso para de funcionar assim que voce mistura CLIs de agentes no trabalho real. Claude Code para um refactor amplo. Codex em full-auto para uma tarefa contida. OpenCode para outro estilo de interação. O chato nao e abrir os processos. O chato e supervisionar tudo junto sem transformar a tela em um monte de abas soltas.
Agora o initech consegue rodar Claude Code, OpenAI Codex e OpenCode lado a lado na mesma TUI.
Muitas ferramentas multi-agent assumem em silencio que todos os painéis executam o mesmo binario. Essa suposição vaza para o comando de launch, para a injeção de texto, para a detecção de prompt e para a tecla de submit.
Quando voce mistura ferramentas, os cantos aparecem rapido. Um CLI espera bracketed paste. Outro trata isso como ruido. Um agente esta realmente pronto em um > simples. Outro ainda esta iniciando servicos ou parado em uma tela de trust. Um prompt de permissao pode congelar uma execucao autonoma inteira.
A mudança visível e role_overrides no initech.yaml. Papeis que fogem do comando global ganham seu proprio array de comando, e agent_type diz ao runtime qual harness usar naquele painel.
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 substitui por completo o comando global. Flags do Claude nao vazam para um papel Codex. E agent_type nao e enfeite: ele escolhe readiness, bracketed paste, submit key e automacoes especificas do CLI.
O problema mais sem glamour em um multiplexador de terminal e submit. Se o submit falha, o resto nao importa.
Claude Code continua no caminho de bracketed paste. Paineis tipo Codex esperam o prompt voltar de verdade, escrevem o corpo direto no PTY, aguardam o detector de paste burst limpar e so entao enviam a tecla de submit.
Codex tem outro ponto chato em fluxos autonomos: prompts de permissao. Um unico confirm pode deixar um papel inteiro parado esperando humano.
Para agent_type: codex, o initech ativa auto_approve por padrao. O painel procura padrões conhecidos no rodape do terminal e envia p para aprovar e lembrar a escolha.
A parte interessante nao e só "agora roda Codex". A parte interessante e que o initech esta caminhando para um multiplexador de terminal agnostico a agente.
Uma interface de operador, uma TUI, um lugar para supervisionar o trabalho. Dentro de cada painel, voce usa o agente que encaixa melhor naquele papel.
Instalação: initech.sh/install.sh
Codigo-fonte: github.com/nmelo/initech
31 de marco de 2026
Overrides de comando por papel: execute Codex, Amp e Claude Code lado a lado
initech nao e mais exclusivo do Claude Code. Com role_overrides no initech.yaml, qualquer papel pode executar um CLI diferente. Codex para um agente, Amp para outro, Claude Code para os demais. Mesmo IPC, mesma deteccao de atividade, mesmo TUI.
Um novo bloco role_overrides no initech.yaml permite sobreescrever o comando padrao por papel:
# initech.yaml role_overrides: codex-eng: command: ['codex', '--full-auto', '--no-alt-screen'] amp-design: command: ['amp']
Cada override mapeia um nome de papel para um array de comandos. O papel continua com seu proprio PTY, seu proprio painel no TUI, e acesso completo a initech send / initech peek. O runtime nao se importa com o que esta dentro do PTY.
O conceito de "agent runtime" era aspiracional ate agora. initech assumia Claude Code em todo lugar: a deteccao de atividade dependia do spinner do Claude, o sistema de eventos fazia parsing dos logs JSONL do Claude, os templates de papeis eram arquivos CLAUDE.md.
Com overrides de comando, as primitivas centrais continuam funcionando. O fluxo de bytes do PTY detecta atividade independente de qual CLI produz a saida. A mensageria IPC opera no nivel do terminal, nao e especifica do Claude. Os templates CLAUDE.md so se aplicam a papeis executando Claude Code; outros CLIs trazem sua propria configuracao.
O que se perde com CLIs que nao sao Claude: parsing de eventos baseado em JSONL (deteccao de conclusao de beads, deteccao de estagnacao) e notificacoes toast baseadas em logs de sessao. Deteccao de atividade e IPC continuam funcionando. Para frotas mistas, os agentes com Claude Code obtem o conjunto completo de funcionalidades; os demais obtem gerenciamento confiavel de PTY e mensageria.
O obvio: voce quer comparar CLIs de agentes no mesmo codebase. Execute um papel de engenheiro com Claude Code e um papel paralelo com Codex. Mesma tarefa, agentes diferentes, visiveis lado a lado.
O pratico: algumas tarefas se adaptam melhor a ferramentas diferentes. Um agente Codex em modo full-auto para refatoracoes simples. Claude Code para mudancas complexas em multiplos arquivos que precisam de mais orientacao. Ambos visiveis e enderecaveis a partir de um unico terminal.
$ curl -fsSL https://initech.sh/install.sh | bash
Codigo-fonte e guia do operador: github.com/nmelo/initech
30 de março de 2026
Coordenação entre máquinas: execute sua frota de agentes em múltiplas máquinas
initech agora suporta coordenação entre máquinas. Execute initech serve em qualquer máquina — uma estação de trabalho, um servidor GPU remoto, uma VM na nuvem — e o TUI local transmite todos os painéis de agentes ao vivo. Um terminal. Todos os agentes. Qualquer máquina.
Adicione mode: headless, peer_name, listen e token ao initech.yaml da máquina remota:
project: myproject root: /home/user/myproject mode: headless peer_name: workbench listen: ":7391" token: "seu-segredo-compartilhado" roles: - eng1 - eng2 - eng3
Inicie o daemon:
$ initech serve
Adicione um bloco remotes: ao initech.yaml local:
project: myproject
root: /Users/voce/myproject
token: "seu-segredo-compartilhado"
roles:
- super
- pm
- qa1
remotes:
workbench:
addr: "192.168.1.100:7391"
Inicie o TUI normalmente:
$ initech
$ initech send workbench:eng1 "inicia o refactor da API" $ initech peek workbench:eng2 -n 30 $ initech peers
28 de marco de 2026
Por Que Construimos um Multiplexador de Terminal para Agentes de IA
Construimos uma TUI em Go que gerencia multiplos agentes Claude Code rodando em paralelo. Ela substituiu o tmux como nosso runtime de sessao.
De a cada agente um terminal rodando Claude Code com instrucoes especificas para o papel. Um agente supervisor coordena. Agentes engenheiros implementam. Um agente QA valida. Um agente shipper faz releases. Cada agente recebe um CLAUDE.md que codifica sua identidade, restricoes, fluxo de trabalho e protocolo de comunicacao.
Rodamos isso em quatro projetos antes de construir o initech. Entregou software real: engenharia paralela, QA independente, gates de release, memoria institucional entre sessoes.
O tmux quebra de tres formas que pioram conforme voce adiciona agentes.
tmux send-keys nao tem garantia de entrega. Voce envia uma mensagem para o painel de um agente e torce para que chegue. Quando nao chega, nao ha erro. Um relatorio de conclusao do eng para o super se perde, super nao sabe que eng terminou, QA nunca e acionado, e o bead fica parado por uma hora.
Um agente travado e um produtivo parecem identicos no tmux. Terminado e no meio do trabalho parecem identicos. A unica forma de saber e espiar cada painel. Com 9 agentes, sao 9 verificacoes manuais a cada 10-15 minutos.
O tmux nao sabe qual trabalho existe, quem esta atribuido a que, ou que um agente acabou de marcar uma tarefa como pronta para QA. Toda orquestracao vive na janela de contexto do supervisor. O contexto compacta. Mensagens se perdem. O agente supervisor esquece que eng terminou. A cadeia de despacho trava.
O tmux e um multiplexador de terminal de proposito geral fazendo um trabalho que precisa de inteligencia no nivel da aplicacao.
Cada sessao roda um Unix domain socket. initech send escreve texto no PTY do agente atraves do emulador, e confirma a entrega. O remetente recebe um OK explicito ou erro em segundos.
$ initech send eng1 "fix the auth bug in middleware.go" $ initech peek eng1 -n 20
Primeiro tentamos monitorar os logs de sessao JSONL. Nao era confiavel: Claude escreve no JSONL nos limites de conversacao, nao de forma previsivel. Durante uma pausa de 45 segundos para pensar, zero entradas. Qualquer timeout esta errado para algum valor de timeout.
O que funciona: rastrear quando o PTY produziu saida pela ultima vez. O spinner do Claude Code anima a 10-30 fps durante o pensamento. O unico estado com zero saida e ocioso-no-prompt. Um limiar de 2 segundos de recencia fornece deteccao binaria limpa.
Ponto verde significa trabalhando. Cinza significa ocioso. Amarelo significa ocioso com tarefas esperando. O overlay mostra o estado de cada agente sem abrir nenhum painel.
JSONL falhou para deteccao de atividade, mas funciona para eventos semanticos. Os logs de sessao contem resultados de uso de ferramentas, mensagens do assistente e sequencias de erro. O sistema de eventos faz parsing desses para:
* Conclusao de bead: agente executou bd update --status ready_for_qa
* Estagnacao: sem saida por mais de 10 minutos com um bead atribuido
* Loops de erro: 3+ falhas consecutivas de ferramentas
* Reivindicacao de beads: auto-detectada a partir dos comandos bd, sem necessidade de chamada CLI extra
Eventos aparecem como notificacoes toast. "eng1 completed ini-bhk.3" aparece em verde antes mesmo do super reportar.
A faixa de cada agente mostra seu bead atual. O overlay mostra o estado de todos os agentes num relance. Quando um agente fica ocioso apos ter um bead, a TUI avisa o agente supervisor diretamente: "[from initech] eng1 is now idle (bead: ini-bhk.3). Check if work is complete."
Cada numero acima foi produzido pela propria ferramenta. O initech gerenciou os agentes que construiram o initech.
A TUI e o runtime. Os templates sao a inteligencia. Um CLAUDE.md ruim produz saida ruim independente de quao boa a TUI seja. Reescrevemos todos os 11 templates tres vezes, cada vez codificando licoes de falhas reais: agentes engenheiros pulando comentarios de PLAN, agentes QA carimbando sem verificar, o agente supervisor fazendo trabalho em vez de despachar.
Tres abordagens antes que a recencia de bytes do PTY funcionasse. Monitoramento de JSONL: muito lento. Taxa de saida do terminal: falsos positivos de SIGWINCH. Deteccao de prompt: fragil a mudancas de UI. A abordagem do spinner so funciona porque o Claude Code sempre produz saida quando esta trabalhando. Uma tela estatica de "thinking..." quebraria isso.
A falha numero um do agente supervisor: fazer implementacao em vez de despachar. Despachar parece lento. Mas o ponto central do multi-agente e especializacao. "Nao usar agentes" agora e o primeiro modo de falha critico no template do supervisor.
Todo agente eventualmente esquece de comentar PLAN antes de codar, ou fazer push antes de marcar ready_for_qa, ou limpar a exibicao do bead. Auto-notify existe porque agentes esquecem de reportar conclusao. Guardrails ajudam mas nao eliminam isso. Conformidade com o processo e um gradiente, nao um binario.
Portabilidade de sessao nao foi iniciada. Mover uma sessao entre maquinas (MacBook para workbench) requer rsync manual. O PRD descreve um comando initech migrate que ainda nao existe.
Gerenciamento de recursos esta atras de uma flag. Auto-suspend/resume sob pressao de memoria (a funcionalidade que dobraria a capacidade efetiva de agentes num laptop de 36GB) esta implementada mas bloqueada atras de --auto-suspend porque a politica nao foi testada o suficiente em sessoes reais.
Onboarding e precario. Um novo usuario que roda initech pela primeira vez ve 7 paineis sem orientacao. Dicas na barra de status rodam na parte inferior, mas nao ha guia do operador documentando o fluxo completo. A ferramenta foi construida pelo seu proprio usuario, e isso se nota.
Adocao inicial. O initech ja foi usado em varios projetos, mas a base de usuarios ainda e pequena. Mais uso no mundo real vai revelar lacunas que o dogfooding nao encontrou.
curl -fsSL https://initech.sh/install.sh | bash mkdir myproject && cd myproject initech init initech
Codigo-fonte: github.com/nmelo/initech