Cuando alguien ve una factura alta de tokens en un sistema con bots de WhatsApp, casi siempre reacciona igual: “hay que cambiar a un modelo más barato”. Suena lógico, pero muchas veces ese no es el problema principal. El verdadero hoyo suele estar en cómo está operado el sistema.
Lo aprendí revisando OpenClaw en operación real. No era solo una conversación con un asistente. Era un ecosistema con WhatsApp, heartbeats, crons, sesiones largas, logs, herramientas, automatizaciones y tareas mezcladas en el mismo hilo. Y cuando juntas todo eso, los tokens se empiezan a ir al carajo aunque el modelo no sea el más caro del mercado.
El primer error: una sola sesión para todo
Si usas la misma sesión para conversar, depurar, revisar emails, coordinar publicaciones, correr automatizaciones y además responder mensajes de WhatsApp, el contexto se vuelve una maleta llena de piedra. Cada turno carga más historial, más instrucciones, más ruido y más costo.
Heartbeats y crons: los asesinos silenciosos
Otro problema serio es cuando conviertes checks rutinarios en conversaciones completas. Un heartbeat que revisa correo, agenda, estado del gateway, pendientes de casa y contexto del día puede ser útil, sí, pero si corre seguido y en la misma sesión principal, empieza a quemar tokens sin que nadie lo note.
Lo mismo con crons mal planteados. Si cada tarea periódica despierta un contexto pesado, lee demasiados archivos, analiza tool outputs gigantes y luego además deja basura conversacional, el costo acumulado se dispara.
Los tool outputs gigantes también cobran
No solo pagas por lo que escribes tú. También pagas por lo que el modelo tiene que leer de herramientas. Si le avientas logs enormes, respuestas JSON kilométricas, docs completas o archivos enteros cuando solo necesitabas tres líneas, ya perdiste.
El bootstrap pesado es deuda permanente
Otra fuga clásica es tener un bootstrap enorme: identidad, reglas, memorias, docs, contexto editorial, instrucciones del canal, políticas, integraciones y archivos extra cargados siempre. Muchas de esas cosas son útiles, pero si todo entra en todos los turnos, pagas el precio una y otra vez.
Qué sí funciona mejor
La mejora real viene de arquitectura operativa, no de un truco mágico.
- Separar sesiones por tarea o dominio.
- Aislar checks rutinarios de la sesión principal.
- Usar compaction cuando el hilo ya creció demasiado.
- Recortar outputs de herramientas al mínimo útil.
- Evitar que una automatización lea archivos enormes si solo ocupa un dato.
- Aprovechar prompt caching cuando el entorno lo permita.
- Reservar el modelo caro para decisiones, redacción o tareas de más valor, no para vigilancia rutinaria.
Entonces, ¿qué modelo conviene?
Sí, el modelo importa. Pero importa después de ordenar la operación.
Para cerebro principal y decisiones delicadas, un modelo fuerte como GPT-5.4 sí tiene sentido. Para research, tareas medianas o volumen controlado, puede convenir algo más barato. Para automatizaciones repetitivas, checks o procesamiento ligero, vale mucho más un flujo compacto que aventar un frontier model a cualquier pendejada.
El punto incómodo
El costo de tokens muchas veces revela desorden. No solo gasto. Te enseña dónde mezclaste tareas, dónde dejaste crecer contexto basura, dónde tus automatizaciones están leyendo de más y dónde tu sistema está diseñado como si el contexto fuera gratis.
Si estás construyendo bots de WhatsApp con memoria, herramientas y automatización, la pregunta correcta no es “¿cuál modelo cuesta menos?”. La pregunta correcta es “¿mi arquitectura merece el modelo que estoy pagando?”.
Porque cuando la operación está bien diseñada, hasta un modelo caro rinde mejor. Y cuando está mal diseñada, ni el más barato te salva.