OpenClaw e Imaginclaw resolvem o mesmo problema

O OpenClaw ultrapassou 100.000 estrelas no GitHub em sua primeira semana. É um agente pessoal de IA open-source, criado pelo fundador da PSPDFKit, que conecta seus aplicativos de chat — WhatsApp, Telegram, Slack, Discord, iMessage — a um agente capaz de agir de verdade: acesso ao shell, controle do navegador, envio de e-mails em seu nome, em loop, sem pedir confirmação a cada vez.

A Imaginclaw faz basicamente a mesma coisa. É aí que a comparação se torna interessante — não porque sejam iguais, mas porque resolvem o mesmo problema a partir de premissas opostas.

O que compartilham

Ambos são gateways auto-hospedados — o processo roda em sua máquina, não na nuvem de um SaaS. Ambos conectam os mesmos tipos de canal a um agente que lê contexto, usa ferramentas e age em loop. Nenhum é "apenas um chatbot".

Onde são separados

O OpenClaw é agnóstico em relação ao modelo por design: Claude, GPT-4o, Gemini ou um modelo local via Ollama funcionam indistintamente, com sua própria chave de API. Essa é uma escolha arquitetural deliberada — flexibilidade total sobre qual motor utilizar. Mas isso tem uma consequência que sua própria documentação não esconde: por padrão, suas mensagens e contexto continuam transitando na nuvem de um terceiro, embora o gateway em si rode em seu hardware.

O Imaginclaw executa sobre o Hera, o runtime local deste mesmo stack. O modelo padrão é local — duas GPUs próprias, sem chamada externa, exceto se configurado explicitamente um fallback. A nuvem é a exceção documentada, não o caminho padrão.

O eixo que importa

"Self-hosted" descreve onde o processo do gateway vive. "Soberano" descreve para onde vão seus dados. São afirmações distintas, e o OpenClaw resolve a primeira sem necessariamente resolver a segunda — algo que sua própria documentação admite abertamente. Nenhum dos dois é "o errado": se você já roda modelos locais para outras coisas, cabear o mesmo padrão de assistente sobre eles é simplesmente a decisão consistente.