Hay un patrón que he notado en casi todos los equipos que construyen agentes de IA por primera vez. Pasan las primeras semanas obsesionados con los costes de tokens. Hacen A/B testing de prompts del sistema. Implementan caché. Cambian de GPT-4 a GPT-4o-mini para consultas simples. Construyen dashboards que rastrean el coste por mensaje hasta cuatro decimales.
Luego llega la factura de la nube.
Es más alta de lo esperado. A veces significativamente más alta. Y cuando la analizan, los costes de tokens están exactamente donde predijeron. La sorpresa es todo lo demás.
Las cinco capas del coste de los agentes de IA
La primera capa son los costes de tokens: lo que pagas al proveedor de IA por solicitud. Esta es la que todo el mundo habla, la que se optimiza primero, y en muchos casos, la parte más pequeña de tu factura total.
La segunda capa son los costes de cómputo: la RAM, la CPU y la infraestructura de servidor que aloja tu runtime de agente. Un runtime que está en reposo a 1,2 GB de RAM no solo cuesta más de alojar —restringe cada decisión arquitectónica que tomas después.
La tercera capa son los costes de arranque en frío, y esta es sigilosa porque no aparece en ninguna factura. El tiempo de arranque en frío es el retraso entre recibir un mensaje y que tu agente esté listo para procesarlo. Cuando ese retraso es de 8 segundos, algunos usuarios asumirán que el bot está roto y se irán.
La cuarta capa son los costes operativos: las horas de ingeniería dedicadas a monitoreo, depuración, actualizaciones de dependencias y respuesta a incidentes. Un runtime con 1.200 dependencias npm no solo tiene una superficie de ataque más grande —tiene una superficie de mantenimiento más grande.
La quinta capa son los costes de oportunidad: las cosas que no puedes construir porque tu infraestructura ya está al límite. Cuando tu runtime de agente consume el 60% de la RAM de tu servidor en reposo, no estás experimentando con arquitecturas multi-agente.
El impuesto de RAM: lo que 1,2 GB realmente te cuesta
OpenClaw está en reposo a aproximadamente 1,2 GB de RAM. En infraestructura en la nube, esto se traduce así: un VPS de 1 GB de RAM —el nivel más barato en la mayoría de los proveedores, típicamente 5-6 USD/mes— no puede ejecutar OpenClaw en absoluto. Un VPS de 2 GB de RAM (10-12 USD/mes) puede ejecutar OpenClaw técnicamente, pero estás usando el 60% de la memoria disponible en reposo. Un VPS de 4 GB de RAM (20-24 USD/mes) es donde OpenClaw realmente corre cómodamente.
ZeroClaw, construido en Rust, está en reposo a aproximadamente 4 MB de RAM. Ese mismo VPS de 5 USD/mes de 1 GB ejecuta ZeroClaw con el 99,6% de la RAM todavía disponible para tu carga de trabajo real. El ahorro anual solo en alojamiento: 84-228 USD, dependiendo de tu proveedor.
Arranques en frío: el coste que no aparece en las facturas
El tiempo de arranque en frío importa en dos escenarios. El primero es el despliegue serverless y en el edge. Si tu agente escala a cero cuando está inactivo, cada primera solicitud después de un período de inactividad paga la penalización del arranque en frío. Para OpenClaw, esa penalización es de aproximadamente 8 segundos. En investigación de experiencia de usuario, los tiempos de respuesta superiores a 3 segundos causan un aumento medible en el abandono.
El segundo escenario son los reinicios. Los fallos ocurren. Las actualizaciones requieren reinicios. Un agente que reinicia en 10 milisegundos es efectivamente siempre disponible. Un agente que tarda 8 segundos en reiniciar crea una ventana de no disponibilidad que, a lo largo de un año, suma horas de tiempo de inactividad.
Para referencia: OpenClaw tarda ~8 segundos en arrancar, PicoClaw ~3 segundos, y ZeroClaw menos de 10 milisegundos.
El impuesto de dependencias: 1.200 paquetes y lo que realmente cuestan
El directorio node_modules de OpenClaw contiene más de 1.200 paquetes. Cada uno de esos paquetes es un coste real y continuo. Desde una perspectiva de seguridad, cada paquete es una vulnerabilidad potencial. Los ataques a la cadena de suministro de ClawHub de principios de 2026 explotaron exactamente esto.
ZeroClaw se distribuye como un binario único enlazado estáticamente. Sin gestor de paquetes. Sin lockfile. Sin resolución de dependencias. Despliega copiando un archivo de 12 MB a tu servidor y ejecutándolo.
Haciendo los números
Para un único agente siempre activo manejando aproximadamente 1.000 mensajes por día:
| Categoría de coste | OpenClaw | ZeroClaw | |--------------|----------|----------| | Alojamiento (VPS) | 288 USD/año (necesita 4 GB) | 60 USD/año (1 GB suficiente) | | Costes de tokens | 180 USD/año | 180 USD/año | | Mantenimiento de ingeniería | ~1.200 USD/año (2h/mes a 50 USD/h) | ~150 USD/año (15 min/mes) | | Impacto de arranque en frío | ~200 USD/año (churn estimado) | Insignificante | | Total | ~1.868 USD/año | ~390 USD/año |
La brecha anual de 1.478 USD es completamente sobrecarga de infraestructura y operaciones. Esa es la diferencia entre un proyecto que es económicamente viable y uno que sangra dinero silenciosamente hasta que alguien lo cancela.
Las implicaciones arquitectónicas
Un runtime que necesita 4 GB de RAM no puede correr en una Raspberry Pi. No puede correr en un VPS de 5 USD/mes. No puede desplegarse en nodos edge cercanos a tus usuarios. Cada una de estas restricciones es una decisión de producto tomada por los requisitos de recursos de tu runtime, antes de que hayas escrito una sola línea de código de aplicación.
Un runtime que usa 4 MB de RAM y arranca en 10 milisegundos puede correr en cualquier lugar. La arquitectura se convierte en una elección en lugar de una restricción.