Nota: entender tokens te ayuda a diseñar agentes más rápidos, estables y baratos de operar a escala.
Ver: Precios
Qué es un token
Un token es una unidad de texto que el modelo procesa. No equivale 1:1 a “una palabra”: puede ser una palabra completa o un fragmento. En una ejecución típica, consumes tokens por:- Entrada: el mensaje del usuario + la instrucción del agente + el contexto que inyectas.
- Salida: la respuesta del modelo.
- Herramientas y nodos: por ejemplo, cuando un nodo trae datos (como un JSON) y esos datos se usan como contexto.
La regla mental: tokens = gasolina
1) Más peso, más consumo
Si tu agente carga demasiadas instrucciones, ejemplos, reglas redundantes o datos innecesarios, el prompt “pesa” más. Causas comunes:- Escribes instrucciones largas o repetidas.
- Incluyes demasiado historial o haces “copypaste” de información en el contexto.
- Recibes respuestas de herramientas con payloads grandes.
2) Mientras más lejos viajas, más gastas
Las conversaciones con muchos turnos tienden a acumular contexto útil… y a veces también ruido. Si tu flujo depende de historial largo, considera:- Resumir o normalizar información clave.
- Guardar solo lo que necesitas para el siguiente paso (no todo el chat).
3) El modelo también importa
Los modelos más “grandes” o con más capacidades suelen ser más costosos de ejecutar. En general:- Usa un modelo especializado o liviano para tareas simples (routing, validaciones, extracción).
- Reserva un modelo más capaz para razonamiento complejo o generación más rica.
Qué suele disparar el consumo en un flujo
- Prompts extensos (sobre todo si incluyes texto repetido).
- Integraciones/API que retornan demasiado contenido (catálogos enormes, logs, JSONs sin filtrar).
- Variables persistidas sin criterio que vuelves a incluir en cada paso.
- Respuestas largas cuando el usuario solo necesita una salida corta/estructurada.
Señales de alerta
Si notas alguno de estos síntomas, probablemente estés consumiendo más tokens de los necesarios:| Síntoma | Causa probable | Solución |
|---|---|---|
| Latencia alta (>5s) | Contexto muy grande | Reduce historial, filtra datos |
| Respuestas cortadas | Límite de salida alcanzado | Pide respuestas más cortas o estructuradas |
| Error “context length exceeded” | Entrada supera el límite | Reduce instrucciones o contexto |
| Respuestas inconsistentes | Demasiado ruido en el prompt | Limpia y prioriza información relevante |
| Costos inesperados | Tokens de herramientas/API | Filtra respuestas de integraciones |
Ejemplo: antes vs después
- Antes (pesado)
- Después (optimizado)
Buenas prácticas para optimizar (sin perder calidad)
Haz prompts “delgados”
Un buen prompt suele ser:- Breve
- Con reglas claras
- Sin ejemplos innecesarios
- Con formato de salida explícito (si aplica)
Decide dónde vive cada dato: Context vs Memory
No todo debe persistir.- Context: vive solo durante la ejecución actual. Úsalo para cálculos temporales y pasos intermedios.
Ver: Contexto - Memory: persiste entre conversaciones/skills con control de tiempo de vida (TTL). Úsalo para datos que realmente reutilizas (por ejemplo, preferencias o identificadores).
Ver: Memory
Limita la información que traes de herramientas
Si usas API, filtra desde origen:- Pide solo los campos necesarios.
- Pagina resultados.
- Evita traer blobs o catálogos completos “por si acaso”.