Coste de tokens: flujos lineales frente a orquestación de agentes
La mayor parte de una factura de automatización no es razonamiento. Son las mismas instrucciones, los mismos esquemas y el mismo JSON, pagados otra vez en cada nodo. Dónde se esconde y cuánto cuesta.
La factura creció más rápido que el tráfico. El volumen subió un 30% y el gasto de API se duplicó, y nadie sabe señalar la funcionalidad que lo hizo. Esa diferencia tiene una explicación estructural, y no está en el razonamiento: está en lo que el grafo transporta entre nodos.
Dónde se esconde el gasto en los grafos de Make y n8n
Un flujo lineal no tiene memoria entre pasos. Cada nodo que llama al modelo es una llamada sin estado: no sabe nada de la anterior, así que todo lo que necesita tiene que viajar con ella. En la práctica eso significa que cuatro pasajeros se suben a cada llamada.
- El prompt de sistema. Escrito una vez, enviado siempre. Tres nodos de modelo en un flujo son las mismas instrucciones pagadas tres veces por ejecución.
- Las definiciones de herramientas y esquemas. La mayoría de integraciones mandan el conjunto completo de herramientas disponibles en cada llamada, pueda o no este paso usarlas.
- La salida completa del paso anterior. La forma más fácil de unir dos nodos es pasar el JSON entero. El modelo necesita dos campos; le llegan cuarenta.
- La conversación acumulada. En los nodos de agente, el intercambio completo vuelve a viajar en cada turno, y solo crece.
Nada de esto se ve en el editor. El lienzo enseña una flecha limpia entre dos cajas; la flecha lleva varios miles de tokens, y los pagas a tarifa de entrada en cada ejecución.
Reinyección de esquemas e hinchazón del prompt
La reinyección de esquemas es la mayor de estas fugas y la menos evidente. La definición de una herramienta no es texto libre: es un esquema JSON con nombres, tipos, descripciones y anidamiento, y un conjunto realista de seis o siete herramientas se va a cerca de mil tokens. Mandarlas todas a un paso cuyo único trabajo es clasificar un ticket en tres categorías es desperdicio puro — y es la conducta por defecto en casi todas partes.
La hinchazón del prompt es el mismo fallo aplicado a los datos. Un nodo devuelve una respuesta de API con cuarenta campos; el siguiente la pasa entera, porque pasarla entera es un clic y elegir campos son diez. El modelo lee los cuarenta, razona sobre dos, y tú pagaste cuarenta.
El token más barato es el que no envías. El segundo más barato es el que envías una sola vez.
Flujos deterministas frente a agentes por objetivo
Conviene ser justo aquí, porque no es un caso en el que una arquitectura gane en todo.
| Flujo lineal | Orquestación agéntica | |
|---|---|---|
| Camino del trabajo | Fijo, idéntico en cada ejecución | Elegido por caso |
| Llamadas por ejecución | Constante y predecible | Variable — a veces menos, a veces más |
| Contexto transportado | Todo, en cada llamada | Lo que este paso necesita |
| Coste de un caso simple | El mismo que el de uno difícil | Bajo — para cuando acaba |
| Coste de un caso difícil | Falla o pide otra rama | Más alto, y termina |
| Auditabilidad | Excelente — se lee el grafo | Exige trazado por ejecución |
La asimetría clave: un flujo lineal paga su coste de peor caso en cada ejecución, porque el camino no se adapta. Un agente paga más o menos lo que vale cada caso. Si el 80% de tus casos son simples, esa diferencia es la mayor parte de tu factura.
Controles de coste: poda y esquemas estrictos
Tres controles hacen casi todo el trabajo, y vale la pena aplicarlos estés en la plataforma que estés:
- Poda semántica del contexto. Lo que viaja al modelo es lo que este paso necesita para decidir, no todo lo que pasó antes. El contexto viejo se compacta en un resumen en vez de transportarse literal.
- Selección condicional de herramientas. Solo se manda el esquema de las herramientas plausibles para el paso actual. Las otras seis existen y no cuestan nada hasta que son pertinentes.
- Esquemas de salida estrictos.
additionalProperties: falsey un conjunto cerrado de campos. El modelo devuelve los campos y nada más, lo que acorta la salida y elimina toda una clase de fallos de parseo.
En Bentho son valores por defecto y no opciones, y esa es la única razón por la que aguantan con el tiempo: un control de coste que hay que acordarse de aplicar en cada flujo nuevo es un control que dejarás de aplicar al tercer mes.
Un modelo sencillo de ROI para el presupuesto de API
Toma un flujo de soporte: clasificar un ticket entrante, buscar el contexto de la cuenta, redactar una respuesta. Tres llamadas al modelo. Supongamos un prompt de sistema de 400 tokens, 900 tokens de definiciones de herramientas, un payload JSON de 2.500 tokens transportado entre pasos y un ticket de 600 tokens.
| Por ejecución | Flujo lineal | Agente con poda |
|---|---|---|
| Prompt de sistema | 400 × 3 = 1.200 | 400 × 1 = 400 |
| Definiciones de herramientas | 900 × 3 = 2.700 | ~250 × 3 = 750 |
| Payload transportado | 2.500 × 3 = 7.500 | ~700 × 3 = 2.100 |
| El ticket en sí | 600 × 3 = 1.800 | 600 × 1 = 600 |
| Contexto del turno anterior | — | ~300 × 2 = 600 |
| Tokens de entrada por ejecución | 13.200 | 4.450 |
| Tokens de salida por ejecución | ~900 | ~900 |
A 10.000 ejecuciones al mes eso son 132M tokens de entrada frente a 45M — una reducción del 66% en el gasto de entrada. A un precio de entrada de 3 USD por millón de tokens, unos 396 USD al mes pasan a ser unos 134. La cifra absoluta es pequeña a ese volumen y lo que viaja es la proporción: se mantiene a 100.000 ejecuciones, donde ese mismo 66% es la diferencia entre una línea del presupuesto y una conversación con finanzas.
Dos matices que conviene decir claro. La orquestación agéntica tiene varianza — un caso difícil puede gastar más llamadas de las que habría gastado el flujo fijo, así que el ahorro aparece en el total mensual y no en ninguna ejecución concreta. Y el cacheo de prompts, donde tu proveedor lo ofrezca, recorta bastante la parte de prefijo repetido de la columna lineal; ayuda, y no toca el payload transportado, que es la fila más grande de la tabla.
El ejercicio útil no es fiarse de esta tabla. Es hacer el mismo desglose contra uno de tus flujos: cuenta los tokens que manda de verdad cada nodo, y mira cuántos de ellos son los mismos tokens que ya pagaste en el nodo anterior.
Preguntas frecuentes
¿Los agentes son siempre más baratos que los flujos lineales?
No. Un agente sale más barato cuando los casos varían en dificultad, porque para cuando termina en vez de recorrer un camino fijo siempre. Para trabajo genuinamente uniforme y sin ramificación, un flujo determinista es más simple, más auditable y cuesta más o menos lo mismo.
¿El cacheo de prompts resuelve esto?
En parte. El cacheo ayuda mucho con el prompt de sistema repetido y las definiciones de herramientas, que son una porción real del desperdicio. No hace nada con el payload transportado —el JSON completo que se pasa entre nodos— porque cambia en cada ejecución, y en el modelo de arriba esa es la fila más grande.
¿Por qué un esquema JSON estricto reduce el coste?
Porque un esquema flojo invita al modelo a añadir campos, repetir la entrada y explicarse, y todo eso son tokens de salida, que suelen facturarse a varias veces la tarifa de entrada. Un esquema cerrado con additionalProperties: false acorta las respuestas y elimina una clase de reintentos por fallo de parseo, que es un segundo ahorro.
¿Cómo lo mido en mis propios flujos?
Coge un flujo y registra durante una semana el número de tokens de entrada de cada llamada al modelo. Después, por cada llamada, estima qué fracción es prompt de sistema, esquemas de herramientas y payload de paso. La parte que no es la tarea en sí es tu techo de mejora.