Cuánto gasta un equipo en agentes de IA y cómo medirlo

En el post anterior, "Tokens al mando", conté cómo pasamos de la intuición a la medición por tarea y por agente. Cuando los equipos dan ese paso, aparece una pregunta que me hicieron varias veces: ¿cuánto estamos gastando realmente y en qué?
No es una pregunta trivial. Cuando los agentes de IA pasan de ser un experimento a ser parte del flujo de trabajo diario, el costo deja de ser una línea marginal y empieza a competir con otras partidas del presupuesto de ingeniería. Y como con cualquier gasto que crece rápido, lo primero que hace falta no es cortarlo: es verlo con claridad.
Comparto cómo pienso este problema, con foco en tres cosas concretas: cómo elegir el modelo según la tarea, qué registrar cuando una tarea termina, y qué mirar en un tablero de costos para que realmente cambie decisiones.
Elegir el modelo según la tarea, no según la costumbre
Uno de los errores más comunes que vi es usar el mismo modelo para todo. Es entendible: una vez que un equipo encuentra un modelo que "funciona bien", la tentación es dejarlo fijo en todos los agentes y flujos. El problema es que eso mezcla tareas muy distintas bajo el mismo costo, y ahí es donde el gasto se vuelve invisible.
Lo que me funciona es pensar en al menos tres niveles de modelo según la exigencia real de la tarea:
- Económico: para tareas repetitivas, de bajo riesgo, donde el margen de error tolerable es alto. Clasificar texto, resumir tickets, extraer datos estructurados de un formato conocido. Acá el objetivo es volumen, no sofisticación.
- Estándar: el punto medio para la mayoría del trabajo diario de un agente: razonamiento moderado, generación de código sobre contextos conocidos, respuestas a usuarios con contexto acotado.
- Alto: reservado para tareas donde el costo de un error es alto o donde el razonamiento en varios pasos es imprescindible: decisiones que afectan a un cliente, planificación compleja, código en sistemas críticos.
La clave no es "el mejor modelo disponible" sino el modelo adecuado para esa tarea específica. Un agente que usa el nivel alto para clasificar emails gasta presupuesto en algo que el nivel económico resuelve igual de bien. Y al revés: un agente económico intentando resolver un problema que necesita razonamiento profundo va a fallar, reintentar, y terminar costando más en tokens (y en tiempo) que si hubiera usado el modelo correcto desde el principio.
Esta decisión de "qué modelo para qué tarea" no debería ser una configuración fija y olvidada. Conviene revisarla con datos, y ahí entra el segundo punto.
Registrar tokens de entrada y salida al cerrar cada tarea
Si en "Tokens al mando" hablamos de medir por tarea y por agente, el siguiente nivel de detalle es registrar, al cerrar cada tarea, los tokens de entrada y los de salida por separado.
¿Por qué separarlos? Porque tienen dinámicas de costo distintas y dicen cosas distintas sobre el comportamiento del agente:
- Muchos tokens de entrada suelen indicar que el contexto que se le da al agente es demasiado grande: historial completo cuando bastaría un resumen, documentos enteros cuando alcanza un fragmento relevante.
- Muchos tokens de salida pueden indicar que el modelo está siendo verboso, repitiéndose, o que la tarea requiere generar mucho contenido (lo cual puede ser legítimo, pero conviene saberlo).
Registrar esto al cierre de cada tarea —no como un promedio agregado a fin de mes— permite después cruzar el dato con el modelo usado, el esfuerzo aplicado y el resultado obtenido. En este sitio, cada tarea y cada ciclo registra modelo, esfuerzo y tokens, y esos datos se ven reflejados en una vista de costos. No es un reporte que se arma a mano después: es parte del cierre natural de cada trabajo del agente.
Esa granularidad es lo que convierte un tablero de costos en una herramienta de decisión y no en una curiosidad contable.
Qué mirar en un tablero de costos y qué decisiones cambia
Tener los números no sirve de mucho si el tablero se convierte en un número grande al final del mes que nadie sabe explicar. Lo que busco al revisar un tablero de costos de agentes es responder preguntas concretas, no solo "cuánto gastamos":
¿Qué tareas concentran el gasto? Si una gran parte del costo está en un tipo de tarea, esa es la primera candidata para revisar si el modelo elegido es el correcto o si el flujo se puede optimizar antes de tocar nada más.
¿El esfuerzo aplicado corresponde a la complejidad real? Cuando el tablero muestra esfuerzo y modelo por tarea, es más fácil detectar desalineaciones: tareas simples resueltas con modelos caros, o tareas complejas resueltas con el mínimo esfuerzo (lo que probablemente explique reintentos o resultados de baja calidad).
¿Hay agentes con tokens de entrada desproporcionados? Casi siempre es una señal de que el contexto que se les pasa se puede recortar sin perder calidad de resultado.
¿El costo por tarea sube o baja en el tiempo? Una tendencia sostenida en cualquier dirección es más útil que un número puntual. Si sube, hay que entender si es porque las tareas son más complejas o porque el flujo se degradó. Si baja, vale la pena entender qué cambio lo causó para replicarlo en otros agentes.
Estas cuatro preguntas, respondidas con datos reales de tokens, modelo y esfuerzo por tarea, son las que en la práctica cambian decisiones: cuándo bajar de nivel de modelo, cuándo vale la pena resumir o recortar contexto, y dónde poner atención antes de que el gasto se vuelva un problema de presupuesto en vez de una palanca de eficiencia.
Qué me llevo
- Medir tokens por tarea y por agente saca al equipo de la intuición; el valor real aparece al traducir esa medición en decisiones.
- Elegir el modelo según la tarea, y revisarlo con datos, evita tanto el gasto invisible como los reintentos costosos.
- Registrar tokens de entrada y salida por separado, al cerrar cada tarea, da más información que un promedio mensual.
- Un tablero útil responde preguntas concretas: dónde se concentra el gasto, si el esfuerzo corresponde a la complejidad y cómo evoluciona el costo por tarea.
Si estás trabajando en algo parecido o tu equipo está evaluando cómo incorporar y medir agentes de IA, me interesa intercambiar experiencias: podés escribirme por LinkedIn. Y si querés conocer más sobre cómo trabajo, lo cuento en https://estebanburgos.com.ar/about-me.

Sobre el autor
ESTEBAN BURGOS · Tech Lead Frontend · Ingeniero de soluciones de punta a punta
Construyo software de punta a punta para pymes y empresas: webs, plataformas y soluciones con IA. Escribo sobre lo que aprendo en proyectos reales.
Conocé mi trayectoria¿Querés algo así en tu empresa?
Contale tu idea a Tuki y en minutos tenés un rango de precio en tu moneda.
Seguí leyendo
- SDD en la práctica: la plantilla de spec que uso con agentes de IALa plantilla de spec que uso a diario con agentes de IA, con el porqué de cada sección: resumen, criterios de aceptación y los gates que evitan que el código avance sin especificación. También cómo elijo entre flow lite y full y por qué registro el consumo de tokens.
- De chatbot a agente: cómo diseñé un asistente de IA que ejecuta acciones con confirmación humanaTe cuento cómo pasé de construir chatbots que solo responden preguntas a diseñar agentes de IA que operan sobre las entidades reales de una plataforma, con function-calling, RAG propio y un paso de confirmación humana antes de ejecutar cualquier acción. Además, cómo controlamos el costo midiendo antes de gastar.
- Lecciones de construir una plataforma de trading para una empresa de energía: seguridad, tiempo real y backofficeComo Forward Deployed Engineer participé, junto a un equipo, en una plataforma de inversiones y trading para una empresa del sector energía con su backoffice de operaciones. Comparto aprendizajes de arquitectura y de proceso, sin código ni datos internos.
Comentarios
Sé el primero en comentar.