Beta oficial do Hermes Mobile: o que os apps de iOS e Android fazem de verdade (e onde ainda quebram)

Você entrega a tarefa de pesquisa ao Hermes que está na sua mesa, pega o celular e vai para o elevador. No terceiro andar você lembra: o escopo ficou largo demais. Só artigos científicos, sem posts de blog.
Antes, isso significava carregar a ideia na cabeça até voltar para a mesa — ou abrir o Telegram e digitar um parágrafo de contexto. Esta semana surgiu uma resposta oficial: um app do Hermes para o celular. Este texto não repete o “finalmente chegou”. Ele responde às três perguntas que importam: o que foi lançado, se você consegue instalar hoje e o que funciona de fato depois de instalar.
O celular é um controle remoto. O agente não muda de lugar.
Esse é o ponto mais mal compreendido do Hermes Mobile, e o anúncio oficial é explícito: o app se conecta ao seu próprio gateway do Hermes. Modelo, ferramentas, memória, arquivos do projeto — tudo continua na máquina onde já estava. O celular cuida de três coisas: conversar, acompanhar o progresso e tocar em “aprovar”.
App no celular (chat / voz / aprovações / status)
| conexão autenticada (endereço direto, túnel SSH ou Tailscale)
v
Seu gateway (hermes dashboard ou hermes serve, porta padrão 9119)
|
v
Modelos | ferramentas | skills | arquivos do projeto | cron
Com essa divisão clara, quase todo o comportamento da beta faz sentido. O relato de um testador em 31 de outubro mostra bem: depois de uns 55 minutos o app Android travou e morreu, enquanto o mesmo turno continuou rodando no servidor e terminou normalmente — o único vestígio no backend foi um WebSocket fechando com código 1006 (issue #147323). A interface caiu; o trabalho não.
O contrário também vale. Quando o celular diz que não conecta, raramente o app é o culpado: ou o caminho entre celular e gateway está errado, ou a autenticação do próprio gateway não passou.
O que foi lançado, exatamente
Em 30 de outubro de 2026, na NousCon em Nova York, a Nous Research abriu a beta móvel oficial e centralizou tudo em hermes-agent.nousresearch.com/mobile. A página faz uma coisa só: você escolhe a plataforma e ela entrega um convite.
| Item | Situação real |
|---|---|
| iOS | Convite público no Apple TestFlight |
| Android | Firebase App Distribution — não é Google Play |
| Nome do pacote | ai.nousresearch.hermes.mobile |
| Versão | 1.0.0; os relatos de teste citam o build versionCode 21 |
| Lojas | Nenhuma das duas plataformas está nas lojas; não há data de lançamento geral |
Segundo o anúncio oficial, a proposta tem três itens: chat com streaming, aprovação de chamadas de ferramentas pelo celular e gestão de bots e routines de qualquer lugar.
Um detalhe merece parágrafo próprio. Cinco dias antes da beta, a Nous avisou publicamente que ainda não existia app oficial nas lojas e que aplicativos de terceiros usando o nome e a cara do Hermes eram provavelmente golpe, não projeto comunitário. Então não procure na loja: comece sempre pela página oficial.
Existe também uma confusão de nomes que vale conhecer: a entrada Hermes Mobile no nosso diretório de ecossistema é um cliente Android feito pela comunidade, sem relação com este lançamento. Mesmo nome, projeto diferente.
Dá para instalar hoje? Confira as duas portas antes
A beta estar aberta não significa que o convite funcione quando você clica. Eu verifiquei os dois links hoje, 2 de novembro, e essa é a parte que a cobertura costuma pular.
O convite de iOS está morto no momento. A página oficial entrega testflight.apple.com/join/U8e1zmbc, que devolve 404 — a página “Not Found” crua da Apple, com 896 bytes, e não a tela de “esta beta está cheia”. A diferença importa: uma beta lotada ainda mostra a página do app e diz que lotou; um 404 significa que o link público em si não está mais ativo (revogado, expirado ou substituído). Enquanto isso, /mobile continua respondendo 200 e servindo o mesmo link antigo. Várias pessoas reproduziram o 404 com user agent de desktop, de iPhone e de TestFlight, além de parâmetros para furar cache (issue #147556 e os comentários da issue #147269).
O convite de Android está no limite de testadores. Abra o link do Firebase, entre com a conta Google e a mensagem é direta: This app is at the tester limit, com a sugestão de pedir ao desenvolvedor para liberar vagas. Várias pessoas, em máquinas e contas diferentes, confirmaram o mesmo resultado (veja os comentários da issue #147269).
Ou seja, o estado real é este: uma parte das pessoas já usa o app e abre bugs; o resto está na porta esperando vaga ou link consertado. Não é a sua rede e não é bloqueio regional.
O que o seu backend precisa ter
O app sozinho é uma casca vazia: ele precisa de algo para conversar. Pelo que aparece nos relatos, a lista de verificação é esta:
- Suba o gateway. Normalmente
hermes dashboard(porta 9119 por padrão, com autenticação do dashboard) ouhermes servepara a parte web. As flags estão na referência do comando hermes dashboard. - Deixe o caminho roteável a partir do celular. Mesma rede Wi-Fi é o caminho fácil. Fora dela, Tailscale é o que os testadores mais usam; o app também tem modo de túnel SSH.
- Não exponha a porta 9119 para a internet aberta. Atrás dela existe um agente que executa comandos e lê arquivos. Acesse pela faixa do Tailscale, ou coloque o Tailscale Serve na frente para HTTPS e aponte
webapp.public_urlpara essa origem. - Defina a autenticação. O app aceita dois caminhos: login no navegador com conta Nous (o callback cai em
/auth/callback) ou o modo Direct com endereço mais senha, usando obasic_authdo dashboard. - Instale o plugin de push se quiser notificações. O gateway precisa do
hermes-mobile-push, e ele não aparece no catálogo hoje —hermes plugins search hermes-mobile-pushdevolveNo catalog entries matched, então precisa ser copiado à mão para o diretório de plugins do usuário (issue #147651). Sem isso, não espere push de “resposta concluída”. - Mantenha o backend razoavelmente atualizado. Os backends nos relatos são, em sua maioria, v0.22.5 (2026.9.24).
Mais uma coisa antes de começar: “conectar” não é um modo único. Existe o Direct (endereço mais login no navegador ou senha), o túnel SSH & Mosh e a conexão direta no endereço do dashboard. Cada um falha de um jeito diferente — é exatamente o que a próxima seção mostra.
O que já funciona no 1.0.0
Não existe lista oficial de recursos, e a documentação ainda não tem guia de configuração do celular. Então esta tabela foi montada a partir de relatos reais de testadores, cada um com o número da issue para você conferir.
| Recurso | Estado | Observações |
|---|---|---|
| Chat com streaming | Funciona | Respostas longas e Markdown renderizam; há telas de sessões, Projects e Artifacts |
| Seletor de modelos | Funciona, com falhas de exibição | Lê /api/model/options do gateway; um backend devolveu 69 ids no grupo nous e 407 em custom:openrouter |
| Live Voice | Funciona, aceita interrupção | Não dá para abrir a partir de um chat vazio com o padrão — veja o contorno abaixo |
| Aprovação de chamadas de ferramentas | Citada no anúncio | Aprovar pelo celular é conveniente e, na mesma medida, uma superfície de risco |
| Bots e routines | Citados no anúncio | Entregas de cron caem no Bot Chat, mas renderizam errado no app — veja abaixo |
| Tela System | Funciona | Mostra endereço do host, versão do Hermes, data de lançamento, saúde e modo de autenticação |
| Notificações push | Incompleto | Chega notificação de “pensando”, mas não de resposta concluída; confirme o plugin de push antes |
| Relatórios HTML inline | Ausente | Dashboards gerados chegam como arquivo para baixar, não renderizados no chat |
O Live Voice tem um contorno realmente útil, documentado na issue #147322: por padrão, um chat novo não tem como iniciar a voz ao vivo até você mandar uma mensagem de texto. Mudando Settings → Chat → Collapsed Voice Button de mensagem de voz para voz ao vivo, tanto os chats novos quanto o atalho das configurações rápidas entram direto numa sessão de voz; mensagens de voz comuns continuam disponíveis pelo campo de texto. Nas palavras do testador: iniciar com um toque importa muito ao dirigir. A voz em si, incluindo interrupções, funciona bem.
Seis arestas para conhecer antes de instalar
É uma beta, e estes são problemas registrados, não boatos.
1. Sessões longas comem memória. A linha do tempo do mesmo testador é precisa: cerca de 55 minutos alternando entre voz ao vivo e respostas longas em streaming, depois um ANR (a thread principal esperando coleta de lixo), e treze segundos depois java.lang.OutOfMemoryError com o heap de 256 MB cheio, num Galaxy S25 com Android 17 (#147323). Aconteceu uma vez, e é exatamente o cenário que merece atenção.
2. Respostas longas não rolam. O mesmo testador também registrou rolagem travando e respostas em streaming que não entram na tela (#147321).
3. Os balões de chat cortam o texto. Na primeira renderização o rodapé do balão é cortado no meio da linha, tanto do usuário quanto do agente; rolar para longe e voltar resolve — o conteúdo está intacto, a altura medida está errada (#147723).
4. Nomes de modelo se confundem ao truncar. deepseek/deepseek-v4.1-flash e deepseek/deepseek-v4.1-flash-1017 aparecem como o mesmo deepseek/deepseek-v4.1-fl… no celular, e a diferença está justamente nos caracteres que somem (#147319).
5. O login pode abrir o callback duas vezes. No Android, de forma intermitente: o navegador para numa página de erro invalid_grant enquanto o app, na verdade, entrou normalmente. O log do gateway mostra dois acessos a /auth/callback separados por 697 ms, o segundo consumindo um código já usado — uma aba duplicada perdedora renderizada na tela (#147738). “Funcionou mas disse que falhou” é o jeito mais rápido de fazer alguém repetir um fluxo que já estava certo.
6. WebSockets do chat recebem 403 em gateways remotos. A autenticação passa, o WebSocket é recusado e o app mostra “Hermes signed you in, but turned down the chat connection.” A requisição de upgrade leva um ticket no subprotocolo, sem cabeçalho Origin, vinda de um peer que não é loopback: ela é tratada como conexão nativa local do Desktop e fechada antes de chegar ao portão do ticket (#147361). Trocar para SSH & Mosh não é solução automática: no iOS, SSH e dashboard autenticaram no servidor enquanto o app reportava erro de credencial (#147726).
Duas questões mais operacionais que vale anotar. Primeiro, o plugin hermes-session-reset-policy nunca dispara para sessões com source=gui — o caminho do dashboard, do Desktop e do celular — então essas sessões nunca resetam por inatividade; um usuário registrou 47 compactações de contexto em seis horas e, depois, parou de receber respostas no celular (#147660). Segundo, entregas de cron com deliver: bot-chat aparecem no app como mensagens escritas pelo usuário, enquanto no Telegram a mesma entrega é formatada corretamente como mensagem de bot (#147573).
Sobre o relato de “nenhuma notificação quando a resposta termina” (#147345), o próprio autor fechou a issue, suspeitando de um componente faltando. Como o plugin de push não está no catálogo, a explicação encaixa: provavelmente não é um sistema de notificação quebrado, é um elo faltando na corrente. Se quiser o panorama de notificações no Hermes em geral, nosso guia de notificações e atenção cobre o lado da configuração.
Um teste de aceitação de dez minutos
Não comece instalando um monte de plugins. Passe uma tarefa de baixo risco pelo caminho inteiro primeiro. Esta sequência cobre todos os modos de falha acima:
- Chat novo, pergunte algo que se responde em uma linha. Confirme o streaming.
- Peça uma resposta longa — mil palavras ou mais — e veja se a rolagem acompanha.
- Coloque o app em segundo plano, volte e confira se a sessão e o conteúdo inteiro sobreviveram.
- Inicie o Live Voice, interrompa no meio da frase e veja se ele retoma o fio.
- Dispare uma chamada de ferramenta que exige aprovação. Aprove ou negue pelo celular.
- Abra a tela System e compare versão e saúde do backend com o que o host reporta.
- Anote três coisas: número do build do app, versão do sistema do celular e
hermes --versiondo backend. Esses três transformam “não funciona” num bug report acionável.
Se você ainda está na etapa do backend, comece pelo guia de instalação e depois leia como o app web e o Desktop dividem o trabalho — o app móvel fala com os mesmos endpoints do webapp e o login usa o mesmo handoff (login Nous e handoff para o app aprofunda o assunto).
O que este lançamento muda de fato
Juntando todas as arestas, o posicionamento continua claro: o Hermes Mobile não é “o agente espremido dentro de um celular”. É “você, liberado do escritório”.
O jeito antigo de avaliar um agente era contar ferramentas e modelos. Agora existe uma segunda pergunta: quando não estou perto da mesa, consigo alcançá-lo, acrescentar uma frase, aprovar um comando e manter o trabalho andando? Essa pergunta vale mais que uma lista de recursos, porque decide se você vai ou não confiar uma tarefa longa de servidor a um agente.
A resposta honesta hoje: sim, mas não aposte tudo no celular. Iniciar tarefas curtas, acompanhar progresso, acrescentar um requisito, aprovar um comando, ditar uma ideia — tudo isso já funciona. Esperar que o celular carregue sozinho uma tarefa de várias horas, com toda notificação chegando na hora, é superestimá-lo.
Quando o convite de iOS for substituído e o Firebase liberar vagas, volte à mesma página oficial. E evite APKs de threads aleatórias — o agente na sua máquina merece uma procedência melhor que essa.