OpenClaw e Imaginclaw resuelven el mismo problema

OpenClaw cruzó las 100.000 estrellas en GitHub en su primera semana. Es un agente personal de IA open-source, creado por el fundador de PSPDFKit, que conecta tus apps de chat — WhatsApp, Telegram, Slack, Discord, iMessage — a un agente que puede actuar de verdad: acceso a shell, control de navegador, mandar emails en tu nombre, en loop, sin preguntar cada vez.

Imaginclaw hace básicamente lo mismo. Y ahí es donde la comparación se vuelve interesante — no porque sean lo mismo, sino porque resuelven el mismo problema desde premisas opuestas.

Lo que comparten

Los dos son gateways self-hosted — el proceso corre en tu máquina, no en la nube de un SaaS. Los dos conectan los mismos tipos de canal a un agente que lee contexto, usa herramientas y actúa en loop. Ninguno es "solo un chatbot".

Dónde se separan

OpenClaw es model-agnostic por diseño: Claude, GPT-4o, Gemini o un modelo local vía Ollama funcionan indistintamente, con tu propia API key. Eso es una elección de arquitectura deliberada — flexibilidad total sobre qué motor usar. Pero tiene una consecuencia que su propia documentación no esconde: por default, tus mensajes y contexto siguen transitando la nube de un tercero, aunque el gateway en sí corra en tu hardware.

Imaginclaw corre sobre Hera, el runtime local de este mismo stack. El modelo por default es local — dos GPUs propias, sin llamada externa salvo que se configure explícitamente un fallback. La nube es la excepción documentada, no el camino por defecto.

El eje que importa

"Self-hosted" describe dónde vive el proceso del gateway. "Soberano" describe a dónde van tus datos. Son afirmaciones distintas, y OpenClaw resuelve la primera sin resolver necesariamente la segunda — cosa que su propia documentación admite abiertamente. Ninguno de los dos es "el equivocado": si ya corrés modelos locales para otras cosas, cablear el mismo patrón de asistente sobre ellos es simplemente la decisión consistente.