Olá a todos!
Prefácio: este texto substitui o post que escrevi original sobre o Omnara. Já o tinha escrito há algum tempo, mas só o iria publicar esta semana. Entretanto, na verificação, notei mudanças. E este post é precisamente sobre a correcção é factual. A razão é metodológica, e é essa que me interessa que fique.
Fiz um artigo em tempos sobre o Omnara. Descrevi-o como uma ferramenta open source, com licença Apache 2.0, que nos permitia gerir agentes de IA a partir do telemóvel sem entregar as chaves de casa a ninguém. Instalava-se com um pip install omnara, dava-nos uma sessão de Claude Code sincronizada entre o terminal, a web e o telefone, e a conclusão que tirei foi a conclusão fácil: sendo aberto, podemos auditar, podemos alterar, podemos correr na nossa infraestrutura, logo está tudo bem.
Depois fui verificar os links antes de os deixar na secção final, como faço sempre. E o GitHub disse-me, logo no topo da página, que o repositório tinha sido arquivado pelo próprio dono a 2 de Fevereiro de 2026, e que estava em modo de leitura apenas.
Vale a pena parar aqui um segundo. O argumento inteiro do meu post assentava numa propriedade daquele repositório. E a propriedade tinha desaparecido meses antes de eu escrever a frase.
O que aconteceu?
Convém ser preciso, porque a história não é a história habitual de uma startup que fecha a porta e desaparece com o dinheiro de toda a gente. É bastante mais interessante do que isso.
O aviso que está no topo do repositório diz, em resumo, que aquela versão do Omnara deixou de ser mantida porque foi construída como um invólucro à volta do CLI do Claude Code, e que manter esse invólucro se tornou inviável face ao ritmo de actualizações do próprio Claude Code. A equipa migrou para uma plataforma nova, também em omnara.com, construída sobre o Claude Agent SDK em vez de embrulhar o CLI. O dashboard antigo ficou a funcionar num endereço separado até ao fim de 2025, e para lhe aceder era preciso fixar a versão 1.7.0 do pacote Python. Quem pagava foi convidado a pedir reembolso, recebeu dois meses de créditos na plataforma nova e manteve o preço antigo para sempre. A aplicação móvel, para quem tinha actualizações automáticas ligadas, saltou sozinha para a versão nova. As aplicações web e móvel ficaram integralmente em Apache 2.0, e quem quiser pode compilá-las a partir do código.
O último lançamento do projecto antigo é de Novembro de 2025. Foram setenta e quatro lançamentos e umas centenas de commits em pouco mais de meio ano, o que dá bem a medida do ritmo a que aquilo andou. Ficaram dois mil e seiscentas estrelas e cento e noventa e três forks, que é o fóssil de uma coisa que teve tracção a sério.
E o produto novo não é o produto antigo com outra roupa. Mudou de categoria. O Omnara de hoje apresenta-se como um plano de controlo aberto e agnóstico ao modelo, com uma API para lançar, correr e controlar agentes, e diz explicitamente que se pode auto-alojar ou usar a nuvem gerida deles. Deixou de se instalar com o gestor de pacotes do Python e passou a instalar-se com um executável, através daquela linha de curl para o bash de que todos gostamos tanto.
Portanto: o comando que eu havia publicado não faz o que eu disse que fazia, o endereço do dashboard que eu publiquei já não serve, e o repositório para onde eu apontei como prova de auditabilidade está congelado. Três frases erradas num post que, tirando isso, estava tecnicamente correcto. É mais ou menos assim que a desactualização funciona: não estraga o texto todo, estraga exactamente as partes que sustentavam a conclusão.
O problema que estas ferramentas resolvem continua a ser real
Antes de puxar o tapete, quero deixar claro que o problema é verdadeiro e que a solução tinha mérito. Se acham que estou aqui a dizer que aquilo era fumo, não estão a ler o que escrevi.
Um agente de código consegue trabalhar sozinho durante períodos longos, mas bloqueia sempre na mesma coisa: a pergunta que precisa de vos fazer. Está a meio de uma migração, encontra uma ambiguidade, pergunta, e fica ali parado. Se estão longe da secretária, aquilo pode estar parado dez minutos ou três horas, e a diferença entre as duas depende apenas da vossa agenda. Pior: se o portátil adormece, o trabalho longo morre com ele.
A proposta era razoável e a implementação era engenhosa. O agente corre na vossa máquina, no vosso ambiente real, com os vossos ficheiros e as vossas ferramentas, e o acesso remoto não passa por SSH, nem por reencaminhamento de portos, nem por túneis. As mensagens do agente aparecem no telefone, respondem-se do telefone, e o agente continua. Havia ainda voz, para quando escrever no telemóvel é um castigo, e havia a possibilidade de o trabalho continuar na nuvem deles quando a máquina de casa se desliga.
Isto resolve um incómodo verdadeiro, e resolve-o melhor do que a alternativa aborrecida que eu uso, e a que voltarei mais à frente. A questão nunca foi se funcionava. A questão é o que é que eu aceitei em troca, sem ter feito as contas.
Um wrapper é um edifício construído em terreno alheio
A razão técnica que a equipa deu para desistir da primeira versão é a parte mais instrutiva desta história inteira, e merece mais atenção do que vai receber.
Aquilo era um invólucro do CLI do Claude Code. Para conseguir espelhar a experiência nativa, com as permissões, os modos, as notificações e o resto, o processo lia em tempo real o ficheiro de sessão que o Claude Code deixa no directório do utilizador e interpretava o que saía no terminal. É uma solução inteligente e é a única maneira de fazer aquilo sem colaboração do outro lado. Também é uma solução que depende de um formato que ninguém prometeu manter estável, produzido por uma ferramenta que é actualizada quase semanalmente por uma empresa que não vos deve nada.
Cada actualização do Claude Code era uma hipótese de partir o Omnara. Não por malícia, apenas porque o contrato entre os dois não existia. Uma equipa de quatro pessoas em São Francisco a correr atrás do calendário de lançamentos da Anthropic é uma corrida que se perde por cansaço, não por incompetência, e a decisão de parar e reconstruir sobre um SDK publicado, com uma superfície documentada e estável, foi a decisão certa. Tardia talvez, certa de certeza.
Guardem o padrão, porque ele aparece em todo o lado no nosso mundo. Sempre que uma ferramenta de que gostam funciona por interpretação da saída de outra ferramenta, em vez de funcionar por uma interface que a outra ferramenta se comprometeu a manter, ela está a viver de empréstimo. É verdade para o invólucro do agente, é verdade para o script que faz grep ao output de um comando que muda de formato na versão seguinte, e é verdade para metade das integrações caseiras que todos temos penduradas no homelab. A direcção da dependência interessa mais do que a qualidade do código. Código bom construído sobre uma superfície instável continua a ser código condenado.
“Open source” não quer dizer o que eu deixaria implícito
Aqui é que está o meu erro, e não é um erro factual, é um erro de raciocínio. Eu escrevi, e acreditei, que ser Apache 2.0 resolvia o problema da soberania. Vamos ver o que a licença efectivamente impediu.
Não impediu que o repositório fosse arquivado. Não impediu que o dashboard fosse desligado numa data marcada. Não impediu que a aplicação no telemóvel de quem tinha actualizações automáticas saltasse sozinha para uma plataforma diferente, com um modelo diferente por trás. Não impediu que o comando de instalação mudasse, nem que a categoria do produto mudasse.
O que a licença deu foi o direito de continuar com o código. Que é um direito real, não é retórica, e vale mais do que zero. Só que o direito de continuar com o código não é o mesmo que a capacidade de continuar com o serviço, e é essa confusão que eu ajudei a alimentar.
Convém separar três coisas que costumam andar embrulhadas na mesma palavra.
Código aberto quer dizer que podem ler e alterar. Protege-vos contra a caixa negra e contra o comportamento não documentado. Não vos protege contra o abandono, porque manter um projecto vivo custa tempo de pessoas competentes e essas pessoas foram fazer outra coisa.
Infraestrutura própria quer dizer que a coisa corre em máquinas vossas, com dados vossos, e continua a correr mesmo que o fornecedor deixe de existir amanhã de manhã. É bastante mais forte do que a primeira, e nem sempre vem com ela: um cliente aberto que fala com uma API alojada por outra pessoa é código aberto sem infraestrutura própria, e é exactamente o caso de que estamos a falar.
Formato e protocolo abertos querem dizer que os dados e a comunicação estão num sítio de onde os conseguem tirar sem pedir licença. Esta é a que menos aparece nas conversas e a que mais interessa quando as coisas correm mal, porque é a que determina o custo de sair.
O Omnara antigo tinha a primeira, e tinha a segunda para quem se desse ao trabalho de montar a base de dados e o serviço. Quase ninguém se dava, incluindo eu, porque o serviço alojado era gratuito até dez agentes por mês e depois eram nove dólares. O caminho de menor resistência era usar a nuvem deles, e a licença aberta funcionava como uma espécie de bênção moral para uma decisão que, na prática, era de conveniência. Suspeito que não fui o único a fazer isto, e é por isso que estou a escrever este texto em vez de corrigir três frases em silêncio.
As perguntas que eu devia ter feito antes
O resultado útil desta trapalhada foi uma lista. Passei a percorrê-la antes de escrever sobre qualquer ferramenta que se meta entre mim e a minha infraestrutura, e passei a percorrê-la antes de a instalar, que é ainda mais importante. São seis perguntas e nenhuma delas fala de funcionalidades.
Onde vive o estado? Não o código, o estado. As conversas, o histórico, as chaves, a associação entre a minha máquina e a minha conta. Se vive num Postgres que corre na minha infraesturtura, tenho um problema pequeno quando isto acabar. Se vive numa base de dados de outra pessoa, tenho um problema grande, e o tamanho do problema não muda por o cliente ser aberto.
Qual é o protocolo, e está documentado? Se a ferramenta fala com o servidor dela por uma API REST descrita, posso escrever um servidor meu num fim de semana ou, mais realisticamente, posso saber ao certo o que sai da minha rede. Se fala por um formato interno que muda quando lhes apetece, sou um passageiro.
Consigo correr a parte servidora, hoje, com esforço razoável? Não em teoria. Hoje. Existe um docker-compose que funciona, existem instruções, existe alguém que já o fez e escreveu sobre isso? Havia, no caso do Omnara antigo, e reconheço-lhes esse mérito. A pergunta a seguir é se eu o fiz, e a resposta honesta era não.
O que acontece se desligarem o serviço amanhã? Não daqui a três anos, amanhã. Se a resposta for “fico sem nada até montar a alternativa”, já sei quanto vale aquilo para mim. Se a resposta for “continua a funcionar em degradado”, estou noutro patamar.
A aplicação móvel é um cliente ou é o produto? Esta é subtil e aprendi-a agora. Uma aplicação nas lojas da Apple e da Google não é vossa, mesmo que o código seja aberto. Actualiza-se sozinha, obedece a políticas que não controlam, e pode mudar de plataforma por baixo dos pés de quem não estava a prestar atenção. Foi precisamente o que aconteceu. Se a experiência que vos interessa depende do telemóvel, aceitem que essa parte nunca será totalmente vossa, e decidam com essa informação em cima da mesa.
Quanto custa sair? Em horas, não em dinheiro. Se a resposta for “meia tarde”, instalem à vontade. Se for “duas semanas e perco o histórico todo”, isso não é uma ferramenta, é um casamento, e convém que seja uma decisão consciente.
Nenhuma destas perguntas se responde lendo a página inicial de um projecto. Todas se respondem em vinte minutos com o repositório aberto ao lado, e vinte minutos é pouco para o que está em jogo.
O plano de controlo é o alvo mais apetecível da nossa infraestrutura
Há uma segunda camada nesta história de que não tinha falado o suficiente no post original, e que me parece hoje mais importante do que toda a discussão sobre licenças.
Uma ferramenta destas não é um proxy que vê tokens a passar. É um processo que corre na máquina onde está o código a sério, com as credenciais a sério, que recebe instruções de um canal remoto e as entrega a um agente com acesso ao sistema de ficheiros e ao terminal. Em muitos casos, com capacidade de aprovar alterações. Traduzido: existe um caminho que começa numa notificação no vosso bolso e acaba num comando executado numa máquina que vos interessa.
Isto é uma classe de superfície de ataque diferente de tudo o resto que temos no homelab, e ainda estamos todos a fingir que é apenas mais uma aplicação.
Pensem no encadeamento completo. O agente lê ficheiros, e alguns desses ficheiros vêm de fora: um README de uma dependência, o corpo de um issue, a resposta de uma API, o resultado de uma pesquisa. Se lá dentro estiver texto desenhado para instruir o agente, o agente pode ser levado a formular um pedido que vos aparece no telefone com o aspecto de uma pergunta normal. E vocês estão numa paragem de autocarro, com o telefone numa mão e o café na outra, e a pergunta parece razoável, e a resposta é um toque no ecrã.
Não estou a descrever um cenário exótico. Estou a descrever a sexta-feira de qualquer pessoa que trabalhe assim.
As mitigações não são complicadas, são apenas aborrecidas, que é como as boas mitigações costumam ser. O agente corre numa máquina que não é a minha máquina principal, de preferência numa máquina virtual ou num contentor com o sistema de ficheiros limitado ao projecto. O utilizador do agente não tem sudo. As credenciais que interessam não vivem no ambiente onde ele corre, vivem noutro sítio e são pedidas explicitamente. O trabalho todo passa por Git, num ramo próprio, porque o histórico é o único registo de auditoria que não depende da boa vontade da ferramenta. E há uma lista curta de operações que nunca são aprovadas remotamente, seja qual for a urgência: tocar em produção, apagar seja o que for, mexer em chaves, alterar regras de firewall.
Aprovar num ecrã de seis polegadas
A parte mais desconfortável desta análise não é técnica. A conveniência que estas ferramentas vendem é exactamente aquilo que as torna perigosas, e nenhuma quantidade de segmentação de rede resolve isso.
Uma notificação com um botão de aprovar treina uma pessoa a aprovar. Não é preguiça, é a forma como funcionamos: a interface pede uma decisão binária, o contexto está a três toques de distância, e o custo de ir buscar o contexto é sempre superior ao custo aparente de dizer que sim. Ao fim de quarenta aprovações certas, a quadragésima primeira sai em piloto automático. Foi a mesma dinâmica que estragou a autenticação em dois passos por notificação, e foi ela que criou uma indústria inteira de ataques que consistem, literalmente, em carregar no botão até a vítima ceder.
A regra que passei a seguir é simples e resistiu bem a alguns meses de uso. O telefone serve para ler, para acompanhar, e para dizer que não. Serve para travar uma coisa que está a correr mal, e travar de longe tem imenso valor. Não serve para dizer que sim a nada que toque em infraestrutura real. O sim é dado à secretária, com o diff aberto num ecrã onde ele cabe.
Isto retira metade do encanto da ferramenta, e sei disso. Mas a metade que fica, a de saber o que se está a passar e de conseguir parar aquilo do sítio onde estou, é a metade que resolve o problema verdadeiro. A outra metade resolve pressa, e a pressa nunca foi um requisito, é só uma sensação.
Estarei a ser injusto com o Omnara?
Em parte estou, e devo dizê-lo com a mesma clareza com que disse o resto.
A equipa portou-se bem. Explicaram a razão técnica em vez de inventarem uma história sobre foco e novos horizontes. Ofereceram reembolso a quem pagava, deram dois meses de créditos na plataforma nova, e mantiveram o preço antigo para sempre a esses clientes. Abriram o código das aplicações web e móvel em Apache 2.0 e deixaram o caminho aberto a quem quisesse compilar a versão antiga. Deixaram o dashboard antigo a funcionar durante um período de transição em vez de o desligarem numa quinta-feira à noite. Comparem com o que uma empresa grande faz quando descontinua um serviço, e digam-me se não é melhor tratamento do que o habitual.
E o produto novo, no papel, responde melhor às minhas objecções do que o antigo. Um plano de controlo agnóstico ao modelo, com uma API, com auto-alojamento assumido como opção de primeira classe em vez de nota de rodapé para entusiastas, é precisamente a direcção que eu quero ver. Se cumprir aquilo que a página promete, é uma coisa mais interessante do que o invólucro que eu elogiei.
Está por verificar, e ainda não o verifiquei. Vou instalar, vou correr a parte servidora em casa, vou ver o que sai da rede com o tráfego à minha frente, e escrevo sobre isso quando tiver factos em vez de impressões. O que não volto a fazer é escrever a partir da página de apresentação e da licença.
O problema, para ser rigoroso, nunca foi o Omnara. Foi eu ter usado a palavra “open source” como se fosse uma resposta, quando ela é apenas uma das perguntas.
O que eu uso enquanto isto assenta
Já que critico, tenho de dizer o que faço, e o que faço é entediante.
Os agentes correm numa máquina virtual dedicada, com o projecto montado e mais nada. O acesso a partir de fora é uma rede privada com VPN, com o telemóvel como um par igual aos outros, sem portas expostas seja onde for. Por cima, tmux e mosh, que é a combinação que sobrevive a mudanças de rede, a túneis do metro e a portáteis que adormecem. O agente escreve num ramo, sempre, e eu leio o diff quando chego ao computador. As notificações que preciso mesmo de receber saem de um webhook de três linhas para um canal privado, e são de leitura apenas: nenhuma delas tem botão nenhum.
Isto é pior do que o Omnara em experiência de utilização, e digo-o sem vergonha. Não tem voz, não tem histórico bonito, não tem aprovações com um toque, e obriga-me a escrever num terminal do telemóvel, o que é um exercício de paciência. Tem duas propriedades que compensam: nada disto depende de uma empresa continuar a existir, e nada disto pode ser actualizado por baixo dos meus pés durante a noite. Se amanhã o openvpn desaparecer, a substituição é uma tarde de trabalho e não perco uma linha de contexto.
Quem preferir a conveniência tem argumentos legítimos, e não estou a fingir que a minha escolha é a única defensável. Estou a dizer que ela deve ser feita a olhar para a factura toda, e que a factura inclui uma linha que quase ninguém escreve.
O custo de saída escreve-se antes da entrada
Fica-me daqui uma regra que já apliquei a três decisões desde então e que me parece a coisa mais útil que este episódio produziu.
Antes de adoptar uma ferramenta que se mete entre mim e a minha infraestrutura, escrevo o plano de saída. Não penso nele, escrevo-o, num ficheiro, ao lado das notas de instalação. Onde estão os dados, como se exportam, quanto tempo demora a montar o substituto, o que se perde no processo. É meia página e vinte minutos.
Se conseguir escrever essa meia página, a ferramenta entra sem drama, porque sei o que custa tirá-la. Se não conseguir, a ferramenta pode até entrar, mas entra como aposta, e as apostas não vão para sítios onde correm coisas que interessam.
O post que escrevi sobre o Omnara não tinha essa meia página. Se tivesse, eu teria descoberto o aviso do repositório antes de publicar, e este texto teria sido escrito noutra ordem: primeiro a verificação, depois a opinião. É essa a ordem certa, e é essa a que passo a usar aqui.
Vão verificar os links dos vossos próprios README internos, aqueles que ninguém abre há um ano. Vão encontrar coisas.
Até à próxima.
Nuno
Ligações
- Repositório antigo, arquivado: https://github.com/omnara-ai/omnara
- Plataforma actual: https://omnara.com/
- Página da Y Combinator, útil para perceber o posicionamento novo: https://www.ycombinator.com/companies/omnara
Nota: continuo sem qualquer afiliação com o Omnara. Este texto corrige e substitui o post anterior sobre a mesma ferramenta, que fica no ar com uma remissão para aqui. Este post foi construído com recurso a um LLM privado.