OpenClaw tiene una reimplementación en Go: un binario de 35 MB en lugar de 800 MB de dependencias

OpenClaw, que ha reunido unas 180 mil estrellas en GitHub, tiene ahora una reimplementación independiente en Go. El nuevo proyecto, llamado GoClaw, promete eliminar los principales problemas de la versión en Node.js: dependencias pesadas, un runtime adicional y un despliegue complicado en servidores modestos.

Para qué sirve GoClaw

La principal queja sobre OpenClaw no tiene que ver con sus capacidades, sino con su empaquetado. Para levantar el proyecto original hacen falta Node.js, npm, el propio repositorio y la instalación de un gran conjunto de dependencias que puede crecer hasta 500–800 MB. En la práctica, esto supone un primer arranque lento, conflictos de versiones, problemas con módulos nativos y más puntos de fallo cuando hay que desplegar el servicio rápidamente en un VPS, un miniPC o una Raspberry Pi.

GoClaw resuelve el problema de la forma más directa: en lugar de un ecosistema de runtime y node_modules, el usuario recibe un único binario compilado de forma estática de unos 35 MB. Basta con descargarlo, darle permisos de ejecución y usarlo. Para herramientas que deben quedarse en segundo plano 24/7 esperando mensajes de Telegram, Discord u otros canales, este formato reduce de forma notable la barrera de entrada y simplifica el mantenimiento.

Cómo está construido el proyecto

GoClaw no es un fork ni una envoltura fina sobre el original, sino una versión reescrita desde cero de la pasarela de IA multiagente. El proyecto se conecta a mensajerías, trabaja con varios proveedores de LLM y apuesta por la concurrencia integrada de Go. El artículo lo presenta como una base más natural para escenarios con agentes, donde hay muchas solicitudes paralelas, esperas de respuestas de API y coordinación entre roles.

• Un único binario de unos 35 MB
• Compatibilidad con más de 11 proveedores de LLM
• Funcionamiento a través de 5 canales de comunicación, incluidos Telegram y Discord
• Sistema multiagente con delegación y orquestación
• Tablero kanban para gestionar las tareas de los agentes

La arquitectura se organiza en torno a varios agentes especializados. Uno diseña la solución, otro escribe el código, un tercero revisa las pruebas y un cuarto se encarga de la revisión. Una tarea de alto nivel se descompone automáticamente y sus etapas se reparten en un tablero kanban interno. En Go este escenario resulta orgánico: las goroutines y los canales permiten mantener muchas cadenas paralelas sin complejidad añadida, mientras que en Node.js todo esto suele depender del event loop y las promesas.

Ventajas y limitaciones

GoClaw ofrece no solo compacidad, sino también una economía de ejecución mejor. El material habla de una reducción del consumo de memoria de 3 a 5 veces respecto a la versión en Node.js con una funcionalidad comparable. Es especialmente importante en VPS baratos con 512 MB o 1 GB de RAM, donde cada proceso permanente consume recursos rápidamente. También gana la contenerización: una imagen con una aplicación en Go puede construirse casi solo con el binario, mientras que un servicio en Node.js suele arrastrar una base más pesada y todo el directorio de dependencias.

Pero esta transición tiene un coste. OpenClaw es fuerte no solo por su código, sino por un ecosistema maduro: una gran comunidad, más de 180K estrellas, plugins consolidados, Skills e integraciones. GoClaw todavía es joven, tiene menos usuarios y menos validación en producción. Casi no hay compatibilidad entre ecosistemas: los Skills existentes de OpenClaw no se pueden simplemente tomar y trasladar.

Por eso la elección depende de la tarea: si se necesita un servicio minimalista para trabajo en segundo plano, la versión en Go parece lógica; si importan los plugins, la personalización y la comunidad, el original sigue siendo claramente más fuerte por ahora.

Qué significa

El caso de GoClaw refleja una tendencia más amplia: las herramientas de IA se valoran cada vez más no solo por la calidad de los modelos, sino por el coste de operarlas. Si un agente debe funcionar de forma estable en segundo plano, desplegarse rápido y no exigir cientos de megabytes de dependencias, Go se vuelve una opción cada vez más práctica.

Pero la victoria del lenguaje no es absoluta: el ecosistema y la madurez del producto aún pueden pesar más que la pura eficiencia de ingeniería.