OpenClaw resultó ser un agente autónomo caro: 81 millones de tokens y conflictos con el servidor

OpenClaw parece ser un agente de IA universal que se puede desplegar rápidamente en tu propio servidor e integrar en flujos de trabajo familiares. Pero la experiencia personal de instalación mostró lo contrario: el agente entra fácilmente en conflicto con servicios vecinos, es exigente respecto a modelos y hardware, y el consumo de tokens rápidamente se sale de control.

Monstruo en el Servidor

El autor comenzó con un escenario típico: cogió un VDS funcionando donde había sitios en React, PostgreSQL, n8n y varios bots Telegram simples, e implementó OpenClaw allí. El primer problema surgió casi inmediatamente después de un error de configuración del token de Telegram. En lugar de una reinstalación indolora, el sistema dejó "restos" en systemd, configuraciones y en la carpeta `.openclaw`. Los parámetros antiguos continuaban afectando nuevas ejecuciones, así que el enfoque familiar de "eliminé y reinstalé" simplemente no funcionó.

Luego quedó claro que OpenClaw no se siente bien como vecino en un servidor ya ocupado. Requiere puertos libres, un entorno limpio y configuración predecible. Resolver qué exactamente rompía la instalación tardó horas de correspondencia con otras herramientas de IA y alrededor de un millón de tokens solo para diagnóstico.

La conclusión principal aquí es simple: desplegar OpenClaw en un servidor de producción con servicios ya en funcionamiento es una mala idea. Necesita un circuito separado, de lo contrario la depuración se convierte rápidamente en limpieza manual y reinstalaciones interminables.

No le Gustan los Orquestadores

El siguiente paso parecía lógico: convertir OpenClaw en una de las herramientas dentro de una configuración ya configurada con Docker, PostgreSQL y n8n. La idea era clara — llamar al agente a través de webhooks, habilidades o scripts e integrarlo en cadenas existentes. Pero en lugar de un componente subordinado, OpenClaw se comportó como un sistema autónomo que no quiere seguir las reglas de otro y soporta mal el control externo.

Incluso cuando la solicitud llegaba formalmente, no se transformaba en una respuesta normal para el escenario.

• MCP requería un token dinámico que el orquestrador no podía obtener
• Los webhooks aceptaban solicitudes pero no las pasaban al agente mismo
• La invocación directa de script Python lanzaba el comando pero no devolvía el resultado
• Crear tu propia habilidad se topaba con un error de autenticación

En lugar de un ejecutor de tareas flexible, surgió un "director" autosuficiente que reluctantemente se integra en procesos externos. El autor lo llama ninja: el agente recibe una tarea, desaparece en las sombras y actúa por su cuenta. Para trabajo en solitario esto podría ser un plus, pero para integraciones tal autonomía rápidamente se convierte en un problema. Si necesitas un módulo silencioso dentro de una orquesta grande, OpenClaw es más un obstáculo que una ayuda.

En otras palabras, la fortaleza del agente resultó ser su principal limitación.

"OpenClaw no es un asistente. Es un ninja."

Hardware y Tokens

Otra sorpresa desagradable salió a la luz al conectar modelos locales a través de Ollama. Opciones ligeras como `phi3:mini`, `gemma2:2b` y `gemma3:4b` no encajaban porque no admiten tools o function calling, sin los cuales el agente no puede funcionar correctamente.

Se encontraron modelos compatibles, pero ya en un peso diferente: `qwen2.5:7b`, `llama3.1:8b` y soluciones similares requieren notablemente más recursos. En un VDS con 32 GB de RAM, las respuestas tardaban de cinco a diez minutos cada una, y la ejecución paralela de otros servicios llevaba a errores de memoria.

De esto surgió el segundo nivel de costes. Para operación local estable de OpenClaw, según la evaluación del autor, necesitas un servidor separado con GPU como V100 o RTX 4090 y al menos 12 GB de VRAM, lo que ya son decenas de miles de rublos por mes en alquiler. Intentar escapar a este problema a través de API tampoco ayudó.

Los 5 millones de tokens comprados a DeepSeek fueron consumidos por el agente en una noche con prácticamente ninguna tarea útil: verificaba modelos, recorría perfiles, cometía errores y volvía a golpear la API. Después de cambiar a OpenRouter, tres sesiones durante pocas horas quemaron otros 76 millones de tokens.

En total durante tres días, el consumo llegó a aproximadamente 81 millones de tokens, con una porción significativa yendo no al texto para el usuario, sino a comprobaciones internas y llamadas repetidas a la API.

Qué Significa Esto

OpenClaw parece no ser "otro bot" sino una capa autónoma pesada entre el modelo y acciones reales en navegadores, mensajeros y otros servicios. Para entusiastas esto podría justificarse si necesitas un agente que trabaje por su cuenta.

Pero la promesa de "desplegar y olvidar" no funciona aquí: sin un entorno dedicado, modelos compatibles, monitoreo y un presupuesto claro, el proyecto rápidamente cambia de la categoría de experimento a una partida permanente de gastos.