OpenClaw e Imaginclaw resuelven el mismo problema — ¿por qué importa dónde corre el modelo?
Los dos son gateways personales de agentes de IA que conectan tus apps de chat (WhatsApp, Telegram, Slack, Discord...) con una IA que puede actuar de verdad, no solo responder. Ese solapamiento es lo que hace que valga la pena compararlos — no es un plug forzado.
Lo que tienen en común
Los dos van más allá de una caja de chat. Los dos son gateways self-hosted — corrés vos el proceso, no un SaaS de terceros. Los dos conectan los mismos tipos de canales a un agente de IA que puede leer contexto, usar herramientas, y actuar en loop, no solo responder una vez.
OpenClaw
Un agente personal de IA open-source viral — 100.000+ estrellas en GitHub en su primera semana, creado por el fundador de PSPDFKit. Es model-agnostic: Claude, GPT-4o, Gemini, o un modelo local vía Ollama funcionan indistintamente, con tu propia API key. Tiene acceso a shell, control de navegador, y puede mandar emails en tu nombre, en loop, sin preguntar cada vez.
Imaginclaw
El asistente soberano propio de Paulo, construido sobre Hera — su runtime de LLM local. Corre en su propio hardware (dos GPUs), con modelos locales como el camino real por default, no un modo opcional. La nube es un fallback deliberado y explícito, no la base.
El eje honesto
¿Quién controla el modelo, y qué estás resolviendo en realidad? OpenClaw es open-source en el sentido de licencia — pero por default, tus mensajes y contexto siguen transitando la nube de un tercero (Anthropic, OpenAI, Google), aunque el gateway en sí corra en tu máquina. "Open-source" y "soberano" no son la misma afirmación, y la propia documentación de OpenClaw lo deja explícito — es model-agnostic POR DISEÑO, no soberano por default.
"Self-hosted" describe dónde vive el proceso del gateway. "Soberano" describe a dónde van tus datos. OpenClaw resuelve lo primero por diseño; Imaginclaw se construyó para resolver ambas.
La razón real por la que esta comparación vale la pena
Imaginclaw no se construyó para competir feature-por-feature con OpenClaw. Se construyó porque un gateway self-hosted que igual enruta cada mensaje por la API en la nube de un tercero no resuelve en realidad el problema de soberanía — solo mueve dónde corre el proceso del gateway, no a dónde van tus datos. Si ya corrés modelos locales para otras cosas, cablear el mismo patrón de asistente sobre ellos fue la decisión consistente, no una novedad.