Ao deixar vários agentes de codificação com IA, como Claude Code e Codex, rodando ao mesmo tempo em várias sessões do tmux, comecei a ter problemas. Eu perdia de vista quais sessões tinham terminado, quais estavam bloqueadas esperando por mim, e só percebia que um agente rodando em background tinha atingido o usage limit depois que isso acontecia.
Com tmux, cheguei ao limite, então criei o comux.
comux é um multiplexador no estilo tmux para rodar agentes de IA.
- Exibe em tempo real, na barra lateral, o status dos agentes em todas as sessões (working / ready / blocked)
- Envia notificações de desktop imediatamente quando um agente termina seu turno ou fica aguardando entrada
- Mesmo que você mate o servidor ou reinicie a máquina, ao reiniciar ele restaura cada agente ao ponto da conversa em que estava (diferente do tmux-resurrect, ele reinicia a session)
- Permite acompanhar em tempo real, na status bar, o uso dos agentes e as notificações acumuladas
Por ser um único binário estático sem dependências, roda em qualquer lugar, inclusive em servidores headless via SSH.
Ele faz parte de um projeto maior de terminal (copad), mas o comux pode ser instalado separadamente:
# Instalar apenas o Comux
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Instalar também o Copad (Linux e MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
Relato dos 4 meses de desenvolvimento: https://marshallku.com/dev/road-to-making-my-own-terminal/
Feedback de quem roda vários agentes é bem-vindo.
3 comentários
Também li muito bem o post do blog.
Como alguém que está desenvolvendo um terminal por motivações parecidas, fiquei com algumas dúvidas.
Pessoalmente, acho que talvez nunca tenha havido uma época em que o ambiente de DX mudasse tão rápido como agora, e fosse tão diferente para cada desenvolvedor.
Não sei se o criador também sentiu isso, mas acho que, em momentos assim, é mais vantajoso que o controle esteja nas minhas mãos,
e, quando pensei em qual seria a base da DX na era da IA, concluí que ela seria baseada no terminal.
Usei todos os terminais que estão em alta recentemente, mas a entrada em coreano ainda é fraca na maioria deles, e a DX/UX para usar agentes era inconveniente; por isso cheguei à conclusão de que eu também deveria desenvolver o meu próprio. Segui por esse caminho e acho que, com meu terminal, consegui garantir uma produtividade melhor do que outras pessoas.
No meu caso, para obter controle total,
pensei que também deveria minimizar as dependências de bibliotecas externas, então optei por desenvolver tudo em Zig por conta própria (exceto casos inevitáveis, como WebView).
Vendo o post do blog e o código, fiquei curioso sobre o motivo de vocês terem escolhido Rust e bibliotecas externas existentes no ecossistema Rust, como rataui, em vez de desenvolver tudo internamente.
Pelo texto, parece que também houve problemas causados por dependências de bibliotecas externas.
E, como o WebView é um WebView nativo, a maioria dos ambientes web não é Safari, então parece difícil fazer testes E2E completos nessa parte. Vocês simplesmente delegam isso a ferramentas externas de teste? Ou têm planos de incluir CEF no futuro? Também fiquei curioso sobre isso.
Eu também já uso meu terminal há algum tempo e entrei em uma fase de estabilização, então estou pensando bastante em adicionar recursos, planejar funcionalidades e melhorar a UX. Mas, durante o desenvolvimento, deve ter havido muitos crashes e vários bugs.
Também gostaria de saber em que momento, depois do início do desenvolvimento, ele ficou estável o suficiente para que a execução passasse a ser feita no terminal desenvolvido por vocês, em vez de em um terminal externo.
Olá!
Obrigado por compartilhar sua boa experiência e suas reflexões.
Claro que, com a redução do custo de produzir código, abriu-se um caminho para fazer as coisas internamente, mas, pessoalmente, continuo encarando a adoção de bibliotecas externas independentemente da chegada da era da IA.
Costumo criar algo eu mesmo apenas quando acredito que essas duas condições sejam verdadeiras.
Há vários motivos, mas no fim penso que, por menor que seja um trecho de código, a partir do momento em que começo a mantê-lo, ele entra no escopo em que eu preciso revisar, testar, manter etc., e sempre há custos além de simplesmente escrever o código.
Os problemas que surgiram durante o desenvolvimento envolveram muitos conflitos com programas bem centrais, como window managers; então, se eu também tivesse feito tudo isso build from scratch, acho que teria gasto muito mais tempo implementando e validando do que depurando e testando conflitos com dependências externas.
Além disso, desde que comecei o desenvolvimento venho usando, com bastante sofrimento, a ferramenta que criei, e imagino que isso só tenha sido possível em certa medida porque comecei a desenvolver sobre algumas dependências.
Como no caso em que removi o SwiftTerm no macOS, primeiro trago uma dependência externa para verificar se o conceito que eu quero funciona; quando surge algo que preciso implementar, começo a implementar diretamente, mas mesmo nesse ponto meus programas já estão rodando graças às dependências externas, então posso continuar focando na estabilização e na adição de recursos por cima delas.
Além disso, ao incluir o WebKit, a maioria dos webapps funciona da mesma forma que funcionaria ao abrir um navegador comum!
Ultimamente tenho usado bastante uma ferramenta para controlar um headless browser via CLI e também o Claude in Chrome; além disso, quero evitar colocar Chromium até no terminal e acabar usando memória em excesso. Então, se nada grande acontecer, acho que não devo mudar muito a stack técnica da webview dentro do terminal.
Obrigado pela leitura!
O link de instalação do multiplexador está sendo cortado... Consulte este item no README para instalar apenas o multiplexador.