PokeClaw vs FoneClaw: inferência local ou execução Android governada

Veredito rápido por encaixe

A comparação PokeClaw vs FoneClaw fica mais útil quando começa por encaixe, não por torcida. PokeClaw faz mais sentido para quem quer explorar um agente Android open-source, local-first e próximo da pesquisa de produto: baixar, inspecionar, testar um modelo no dispositivo e observar como um loop de agente lê a interface e escolhe ações. FoneClaw faz mais sentido para quem quer uma rota Android independente com execução governada em tarefas suportadas, aprovações visíveis, continuidade e recuperação quando uma permissão ou estado do telefone muda.

A diferença central é que “local” pode significar duas coisas. A primeira é inferência local: o modelo roda no aparelho, com menos dependência de servidor para raciocinar. A segunda é execução local no Android: o agente age no telefone real, passando por permissões, apps, tela atual, controles do sistema e confirmação do usuário. Um produto pode ser forte em inferência local sem cobrir amplamente execução governada. Outro pode ser forte em execução Android sem prometer que toda inferência fica no dispositivo.

O repositório oficial do PokeClaw descreve o projeto como um protótipo Android local-first e open-source. A página oficial do PokeClaw reforça a ideia de protótipo público, com APK direto, modo local e requisitos de hardware. Na FoneClaw, nossa leitura de produto é outra: o valor aparece quando o usuário consegue transformar intenção em uma ação Android controlada e reversível antes de confiar em tarefas mais sensíveis.

Se você quer estudar o agente, mexer na pilha e testar inferência local, comece por PokeClaw. Se quer testar um agente para celular com foco em execução governada no Android, comece por FoneClaw. Para quem pesquisou alternativa ao PocketClaw, a pergunta prática é a mesma: você precisa de experimento local de modelo ou de um caminho controlado para agir no telefone?

Caminho do modelo e dos dados

O ponto mais forte do PokeClaw é o caminho de inferência local. A documentação oficial informa que o modo local roda Gemma 4 por LiteRT-LM no telefone. Depois da configuração inicial, esse modo não exige conta nem chave de API para funcionar. Para quem avalia privacidade, autonomia de teste e custo de chamada a modelo, essa arquitetura é atraente porque reduz a dependência de provedores externos no caminho principal do raciocínio.

Ao mesmo tempo, PokeClaw também documenta provedores cloud opcionais. Quando o usuário ativa um provedor cloud, o caminho dos dados muda. Isso não invalida o projeto; apenas muda a avaliação. A pergunta correta deixa de ser “PokeClaw é local?” e passa a ser “qual modo está ativo, qual modelo está rodando, que dados saem do aparelho e que tarefa está sendo executada?”.

No FoneClaw, pelas informações de produto mais recentes disponíveis nesta atualização, comunicamos o produto como runtime independente de agente Android, com foco em execução governada, tela atual acionada pelo usuário, continuidade, aprovações, parada, recuperação e roteamento de capacidades. Não tratamos o FoneClaw como promessa de inferência totalmente no dispositivo. Essa fronteira é importante porque confiança em agente móvel depende tanto do modelo quanto da rota de ação.

Para uma discussão mais ampla sobre confiança, nuvem e controle local no Android, veja Confiança em agentes de IA: controle local no Android ou IA em nuvem. Aqui, a comparação fica no que cada produto mostra oficialmente hoje.

Para leitores técnicos, a implicação é direta: local-first não elimina o teste de ação. Um agente pode raciocinar no aparelho e ainda precisar de permissões, leitura de tela, gesto, app correto e fallback. Para usuários finais, a pergunta é mais simples: o produto conclui minha tarefa com clareza e sem surpresa?

Como cada agente observa e age

O PokeClaw documenta um loop de agente residente no telefone: ele lê uma representação textual da interface atual e escolhe ferramentas. Essa abordagem é comum em agentes Android experimentais porque transforma a tela em uma sequência observável para o modelo. O agente então decide se deve tocar, inserir texto, abrir app, ler tela, capturar screenshot, enviar mensagem, acionar auto-reply ou finalizar a tarefa, dentro das ferramentas oficiais descritas pelo projeto.

Esse desenho é valioso para experimentação. Ele permite ver como o agente interpreta uma interface e qual ação escolhe em seguida. Também deixa claro o desafio: interfaces mudam, botões têm rótulos diferentes, permissões aparecem em momentos inesperados e um app pode atualizar a estrutura da tela. Um loop baseado em leitura e ação precisa lidar com variação, bloqueios, repetição e estados ambíguos.

Na FoneClaw, construímos a experiência a partir do caminho de execução governada. O acesso flutuante permite chamar o agente sobre outros apps, e a tela atual entra no contexto quando o usuário solicita. A continuidade de tarefa ajuda a manter o fio entre pontos de entrada. O roteamento de capacidades direciona o pedido para áreas suportadas, como tela e app, estado do dispositivo, navegação, comunicação, calendário, notas, tarefas, workflows, atalhos, Skills e Plugins. A página Assistente de IA flutuante no Android: use a tela atual com controle aprofunda esse fluxo de contexto visual acionado pelo usuário.

A diferença prática aparece quando a tarefa tem efeito. Um agente de IA no dispositivo pode observar uma tela e sugerir o próximo passo. Um runtime de execução precisa decidir se existe ferramenta suportada, se a permissão está disponível, se a ação muda estado sensível e se o usuário deve aprovar. Por isso, a comparação não deve virar “quem toca mais botões”. A pergunta melhor é: quem observa com contexto suficiente, age dentro de limites claros e mostra o resultado?

Permissões, aprovações, parada e recuperação

Controle não nasce automaticamente de código aberto, inferência local ou permissão concedida. O PokeClaw exige Accessibility para leitura de tela e gestos, segundo a página oficial. Esse acesso é poderoso porque permite observar e interagir com a interface. Também exige cuidado: se o agente pode ler estado e agir, o teste precisa verificar quando ele pede confirmação, como lida com mensagens, como evita ficar preso e como falha de modo limpo.

O repositório do PokeClaw discute regras, guards, detecção de travamento, prioridades de QA, limitações e falhas limpas. Esses elementos mostram que o projeto trata controle como parte do problema, não apenas como detalhe de implementação. Ainda assim, o leitor deve testar no próprio aparelho, porque o comportamento depende de app, idioma, estado de permissão, hardware e modo de modelo.

Na FoneClaw, nossa prioridade é deixar ações consequentes sob controle observável. Pelas informações de produto mais recentes disponíveis nesta atualização, a execução trabalha com aprovações, parada, verificação de estado, recuperação de permissões e revisão de ativação quando capacidades adicionais entram no fluxo. Quando uma tarefa envolve mensagem, contato, calendário, localização, configuração do sistema, arquivo ou dado pessoal, o produto deve orientar o usuário pelo caminho de permissão e confirmação em vez de esconder a ação atrás de uma resposta confiante.

O ponto de segurança que vale para os dois produtos é simples: permissões são pré-condição, não consentimento informado para qualquer ação futura. Um agente pode ter acesso técnico e ainda precisar perguntar antes de enviar, alterar, apagar, ligar ou compartilhar. Um bom teste registra se o usuário consegue parar a tarefa, se o app mostra estado final, se uma falha aparece de forma compreensível e se a recuperação retoma a tarefa sem pular aprovação.

Para detalhes sobre camadas de ferramentas, Plugins, Skills, Workflows e Shortcuts na nossa arquitetura, o guia Ferramentas, Plugins, Skills, Workflows e Shortcuts na FoneClaw: guia de camadas aprofunda o que fica fora desta comparação direta.

Instalação, hardware e custo do dispositivo

A instalação do PokeClaw é voltada a quem aceita o perfil de protótipo. A página oficial lista APK direto e requisito Android 9+ em arm64. Para o modo local, ela informa download inicial de cerca de 2,6 GB e necessidade de aproximadamente 4 GB de RAM livre. Também menciona que aquecimento de CPU pode levar em torno de 45 segundos em certas condições, enquanto hardware acelerado suportado pode reduzir a espera.

Esses números tornam o custo do “agente local para celular” mais concreto. Rodar modelo no aparelho economiza chamadas externas e cria uma experiência interessante para privacidade e autonomia, mas transfere parte do custo para armazenamento, memória, bateria, aquecimento e latência local. Um chipset citado em demonstração não garante o mesmo resultado em todo telefone; app instalado, temperatura, bateria, serviços em segundo plano e versão do Android mudam a experiência.

Para quem quer entender a parte técnica de desempenho, Otimização de LLM no dispositivo para agentes de celular explica por que quantização, runtime, memória e aceleração importam. No PokeClaw, essa discussão é central porque o modo local é um dos atrativos do projeto.

O FoneClaw pede outro tipo de verificação. Em vez de começar perguntando se o telefone aguenta um modelo local grande, o usuário deve perguntar se o aparelho suporta as permissões e fluxos Android necessários para a ação pretendida. O caminho atual deve ser conferido pela página de download da FoneClaw, com um teste curto antes de conceder permissões amplas. Para ambos os produtos, a instalação só é o começo; o que decide é o comportamento na tarefa real.

Fluxos em que cada produto faz mais sentido

PokeClaw se encaixa melhor em fluxos de exploração local-first. Um desenvolvedor pode estudar o repositório, ver a licença Apache 2.0 e observar os limites de marca descritos no projeto. Um pesquisador pode testar como um modelo local interpreta a UI. Um usuário técnico pode experimentar navegação genérica por apps e exemplos documentados como auto-reply no WhatsApp, sempre tratando compatibilidade como algo a verificar no próprio telefone.

FoneClaw se encaixa melhor quando o objetivo é transformar pedido em execução Android governada. Na nossa prática de produto, tarefas como abrir app, preparar mensagem, consultar estado, ajustar configuração suportada, navegar, criar lembrete ou usar contexto de tela precisam de uma sequência previsível: entender intenção, escolher capacidade, pedir permissão se necessário, apresentar aprovação quando a ação tem efeito e verificar o resultado. A página de recursos da FoneClaw mantém a visão atual das áreas suportadas e da superfície de ferramentas integradas.

Nenhuma tabela substitui o teste no dispositivo. Um app pode mudar interface, uma permissão pode faltar, um modelo pode responder devagar e uma rotina pode funcionar em inglês, mas não no idioma real do usuário. O melhor comparativo é sempre por workflow: defina uma tarefa, rode nos dois caminhos quando fizer sentido e registre evidência.

Essa leitura também evita uma falsa oposição. Inferência local e execução governada podem se aproximar com o tempo. O mercado de agente Android tende a combinar modelos mais eficientes no dispositivo, ferramentas com contratos melhores, aprovação mais inteligente e recuperação mais clara. O que importa hoje é escolher o caminho que resolve a próxima tarefa sem vender autonomia como atalho para controle.

Escolha e rode um primeiro teste reversível

Escolha PokeClaw primeiro se sua prioridade é testar um protótipo open-source, aprender com inferência local, observar o loop de leitura da UI e aceitar ajustes técnicos. Escolha FoneClaw primeiro se sua prioridade é execução Android governada em tarefas suportadas, com acesso flutuante, contexto de tela acionado pelo usuário, continuidade, aprovações, parada e recuperação.

O primeiro teste deve ser reversível. Evite envio de mensagem real, compra, exclusão, mudança de conta ou alteração permanente. Use algo como abrir um app, ler o estado visível, ajustar volume, preparar uma mensagem sem enviar ou abrir uma rota sem iniciar uma ação sensível.

1. Defina uma tarefa curta, por exemplo: prepare uma mensagem para Ana dizendo que chego em dez minutos, mas não envie.
2. Rode a tarefa no mesmo telefone, idioma, rede e app de destino.
3. Registre pedidos de permissão, latência, uso de tela atual, ferramenta escolhida e visibilidade da ação.
4. Interrompa no meio e veja se o agente para de forma compreensível.
5. Remova uma permissão necessária e repita para avaliar recuperação.

Ao comparar resultados, separe conclusão, controle, verificação, recuperação e repetibilidade. Uma única execução bem-sucedida mostra potencial; repetição em estados diferentes mostra confiança operacional. Para PokeClaw, confira o modo local e qualquer provedor cloud ativo. Para FoneClaw, confira as informações de produto mais recentes disponíveis nesta atualização nas páginas oficiais e comece com uma tarefa de baixo risco. O melhor agente de IA no dispositivo ou no Android governado é aquele que resolve uma tarefa real sem esconder caminho, permissão ou consequência.