Dónde se van los tokens en ingeniería con IA

Cuando trabajas con agentes de IA en software engineering, el costo real no está solo en la API o en el modelo. También está en cuántos tokens quemas en cada paso del flujo: planificación, búsqueda de contexto, lectura de código, generación de parches, revisión y reintentos. Si no mides eso, optimizar se vuelve adivinar.

El paper Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering pone el foco justo ahí: en descomponer el consumo de tokens por etapas para entender qué parte del sistema está inflando costo y latencia. Esa idea sirve tanto si usas un agente para resolver issues como si orquestas varios pasos con herramientas, memoria y validación automática.

Qué significa tokenomics en un flujo con agentes

Tokenomics, en este contexto, no tiene que ver con cripto. Se trata de cuantificar dónde entran y dónde salen los tokens a lo largo de un flujo agentic. Si tu agente lee 200 archivos, resume 20 y genera 3 propuestas de cambio, cada una de esas acciones tiene una huella distinta en tokens, tiempo y dinero.

La ventaja de medir por etapa es simple: deja de ser un costo promedio por request y pasa a ser una distribución real. Eso te permite responder preguntas concretas como: ¿la mayor parte del gasto está en el prompt inicial, en la recuperación de contexto o en las iteraciones de corrección? ¿El cuello de botella es el modelo o la arquitectura del workflow?

En equipos de Latinoamérica esto importa todavía más porque muchas veces el presupuesto es más ajustado y el tráfico es variable. Si un agente cuesta USD 0.08 por tarea en pruebas y luego escala a 20,000 tareas al mes, ya no estás hablando de un experimento simpático, sino de una línea de gasto que merece control fino.

La unidad de análisis no es el request, es la etapa

Un request puede incluir varias cosas: system prompt, historial, contexto recuperado, herramientas, output intermedio y validaciones. Si lo miras como una sola caja negra, no sabrás qué cambiar cuando suba el costo.

La forma útil de medirlo es dividir el flujo en etapas observables. Por ejemplo:

1. Ingesta de tarea: cuánto contexto entra desde el ticket, issue o PR.
2. Retrieval: cuántos tokens se usan para buscar código, docs o historial.
3. Planning: cuántos tokens consume el razonamiento del agente antes de actuar.
4. Execution: cuántos tokens se van en llamadas a herramientas y respuestas intermedias.
5. Verification: cuánto cuesta validar el resultado, por ejemplo con tests o lint.
6. Repair loop: cuánto se gasta cuando el agente falla y vuelve a intentar.

Ese desglose cambia la conversación. Ya no preguntas solo “¿cuánto cuesta el modelo?”. Preguntas “¿qué etapa está multiplicando el costo?”.

Cómo medir el consumo de tokens sin perderte en logs

Medir token usage bien requiere trazabilidad desde el inicio. Si tu stack usa OpenAI, Anthropic o un wrapper propio, necesitas capturar el conteo de tokens por llamada, el tipo de operación y el identificador de la tarea. La documentación oficial de OpenAI explica cómo leer usage en respuestas de la API y cómo estructurar observabilidad alrededor de las llamadas: https://platform.openai.com/docs

La clave es no conformarte con el total por interacción. Para ingeniería con agentes, conviene guardar al menos cuatro dimensiones: etapa, modelo, tokens de entrada, tokens de salida. Si además registras latencia y resultado, puedes cruzar costo con calidad.

No hace falta un sistema complejo desde el día uno. Puedes empezar con un esquema de eventos como este:

{
  "task_id": "issue-1842",
  "stage": "retrieval",
  "model": "gpt-4.1-mini",
  "input_tokens": 1820,
  "output_tokens": 240,
  "latency_ms": 1430,
  "success": true
}

Con eso ya puedes construir dashboards útiles. Por ejemplo, costo por etapa, p95 de latencia por tipo de tarea y tasa de reintentos por modelo.

Métricas mínimas que sí te sirven

Si quieres tomar decisiones, no midas veinte cosas por deporte. Mide las que cambian arquitectura o presupuesto:

• Tokens de entrada por etapa.
• Tokens de salida por etapa.
• Latencia por llamada y por tarea completa.
• Número de iteraciones o repair loops.
• Tasa de éxito en primera pasada.
• Costo por tarea y costo por PR o issue.

Con esas seis métricas puedes detectar patrones. Si el retrieval consume 60% de los tokens y el planning solo 10%, quizá no necesitas un modelo más grande, sino una estrategia mejor de indexación o chunking.

Dónde se van los tokens en la práctica

En flujos de ingeniería con agentes, el consumo se concentra casi siempre en tres sitios: contexto, razonamiento y corrección. El contexto crece cuando le pasas demasiado código, demasiados logs o demasiadas conversaciones previas. El razonamiento crece cuando el prompt pide demasiadas restricciones. La corrección crece cuando el agente falla y vuelve a intentar sin una señal clara de error.

Un ejemplo realista: un agente que arregla bugs en un monorepo puede gastar pocos tokens en la descripción del issue, pero miles en leer archivos relacionados, comparar implementaciones y generar un patch. Si además ejecuta tests y vuelve a analizar el fallo, el costo puede duplicarse en segundos.

Para visualizarlo mejor, piensa en esta distribución típica de una tarea compleja:

Estos rangos no son universales, pero sí sirven como mapa. En muchos sistemas, el verdadero agujero no está en el primer prompt, sino en los reintentos. Un agente que falla tres veces no solo cuesta más; también tarda más y ocupa más infraestructura.

Contexto excesivo: el error más caro

Pasarle al modelo todo el repo es una mala idea casi siempre. No porque el modelo no lo soporte, sino porque vas a pagar por tokens que no aportan señal. En vez de eso, conviene recuperar solo lo necesario: archivos relevantes, símbolos relacionados, tests afectados y diffs previos.

Una técnica útil es medir el ratio entre tokens recuperados y tokens realmente usados en la respuesta final. Si recuperas 6,000 tokens para producir una salida de 300, probablemente estás sobredimensionando el contexto. Si recuperas 1,500 y el agente falla por falta de información, te quedaste corto.

Reintentos: el multiplicador silencioso

Los repair loops suelen esconderse en métricas promedio. Un flujo puede parecer barato hasta que descubres que el 15% de las tareas dispara un segundo o tercer intento. Ahí el costo real se mueve rápido.

Para controlarlo, registra por tarea cuántas veces el agente:

• vuelve a pedir contexto,
• vuelve a generar código,
• vuelve a ejecutar tests,
• vuelve a pedir validación humana.

Si una sola categoría concentra la mayoría de los reintentos, ya sabes dónde intervenir.

Cómo optimizar costo y latencia sin romper el flujo

Optimizar no significa solo cambiar a un modelo más barato. A veces eso reduce costo y empeora latencia o calidad. Lo útil es pensar en tres palancas: menos tokens, menos round-trips y mejor partición de tareas.

La documentación oficial de Anthropic también recomienda prestar atención a la estructura del prompt, al uso de herramientas y al manejo del contexto: https://docs.anthropic.com/

En la práctica, estas son las decisiones que más impacto suelen tener:

1. Reducir contexto con retrieval selectivo en vez de meter todo el repo.
2. Separar planificación de ejecución para no mezclar razonamiento largo con generación de código.
3. Usar modelos pequeños para tareas mecánicas y modelos más capaces solo donde aporten valor.
4. Cachear resultados de búsquedas, análisis estáticos y resúmenes de archivos.
5. Cortar loops de reparación con límites claros de iteraciones.
6. Validar con herramientas determinísticas antes de pedir otra vuelta al modelo.

Si tienes un pipeline con varias etapas, la optimización más rentable suele ser eliminar una llamada, no abaratar cada llamada. Quitar un round-trip de 1,200 tokens ahorra más que reducir un 10% el precio por token.

Arquitecturas que suelen gastar menos

Hay tres patrones que suelen funcionar bien en ingeniería con IA:

• Planner + executor: un modelo planifica y otro ejecuta acciones concretas.
• Retrieve + summarize + act: primero recuperas, luego resumes, después actúas con contexto compacto.
• Tool-first verification: el agente usa tests, linters o parsers antes de pedir una nueva generación.

Cada patrón recorta tokens de forma distinta. Planner + executor evita que el modelo razone y escriba al mismo tiempo. Retrieve + summarize + act reduce contexto bruto. Tool-first verification evita reintentos ciegos.

Un caso común en equipos de software es usar un agente pequeño para leer logs y extraer el error exacto, y luego pasar solo ese error a un modelo más fuerte para proponer el fix. Eso suele ser más barato que enviar todo el log dos o tres veces.

Cómo llevar tokenomics a decisiones de arquitectura

Si ya mides por etapa, puedes convertir tokenomics en una herramienta de diseño. La pregunta deja de ser “¿qué modelo usamos?” y pasa a ser “¿qué parte del sistema merece inteligencia y cuál merece determinismo?”.

Por ejemplo, si el análisis de una tarea muestra que el 70% del costo está en recuperar y resumir contexto, quizá el problema no sea el modelo sino el índice. Tal vez necesitas mejor chunking, embeddings más precisos o una capa de prefiltrado por lenguaje, carpeta o tipo de archivo.

Otro caso: si el 40% de la latencia total ocurre esperando una segunda llamada al modelo después de ejecutar tests, puedes mover parte de la validación al lado de la herramienta. Un parser, un diff checker o un conjunto de reglas puede resolver casos obvios sin gastar tokens extra.

Decisiones concretas que puedes tomar

Usa esta lógica simple para priorizar trabajo:

• Si el costo está en contexto, reduce y recupera mejor.
• Si el costo está en planning, simplifica instrucciones y separa etapas.
• Si el costo está en execution, baja el tamaño del output y limita el alcance.
• Si el costo está en verification, automatiza más con herramientas.
• Si el costo está en repair loops, mejora señales de error y corta iteraciones.

Esto también ayuda a negociar con producto o dirección. En vez de decir “el agente está caro”, puedes decir “el 58% del gasto viene de retrieval y el 22% de reintentos; si reducimos ambos, bajamos el costo por tarea sin tocar calidad”.

Un marco simple para instrumentar tu propio sistema

No necesitas una plataforma enorme para empezar. Puedes instrumentar tu flujo con eventos y luego agregarlos por tarea, modelo y etapa. Lo importante es que cada llamada tenga un ID que puedas seguir de principio a fin.

Un esquema mínimo podría verse así:

type AgentEvent = {
  taskId: string;
  stage: 'ingest' | 'retrieval' | 'planning' | 'execution' | 'verification' | 'repair';
  model: string;
  inputTokens: number;
  outputTokens: number;
  latencyMs: number;
  success: boolean;
};

Con algo así puedes construir preguntas útiles en tu propio stack:

• ¿Qué etapa consume más tokens por tipo de issue?
• ¿Qué modelo tiene mejor relación entre tokens y éxito?
• ¿Qué tareas generan más reintentos?
• ¿Cuál es la diferencia entre p50 y p95 de latencia por flujo?

Si trabajas con GitHub Actions, CI o un backend propio, también puedes adjuntar metadatos como repo, branch, tamaño del diff y tipo de archivo. Eso te deja descubrir patrones como “los cambios en TypeScript cuestan menos que los cambios en infra” o “los PRs grandes disparan más retrieval”.

Tabla resumen

Si quieres aplicar esta lógica en tu equipo, empieza por una semana de medición por etapa. No cambies nada al principio. Solo registra tokens, latencia, éxito y reintentos. Con ese baseline vas a ver rápido si el problema es el modelo, el prompt, el retrieval o el diseño del flujo.

El valor de tokenomics no está en producir un dashboard bonito. Está en darte una forma concreta de decidir dónde poner inteligencia, dónde poner reglas y dónde recortar gasto sin matar la utilidad del agente. En ingeniería con IA, esa diferencia se nota en el presupuesto, en el tiempo de respuesta y en la estabilidad del sistema.