En abril de 2026 el equipo responsable de los Agentic Workflows implantó instrumentación en sus repositorios para capturar con precisión cómo se consumen tokens durante ejecuciones automáticas de integración continua (CI). La iniciativa nació del problema de que muchos workflows se lanzan en cada pull request y, al ser automáticos, generan costes de API acumulados sin visibilidad clara. Para obtener datos comparables y trazar consumos históricos introdujeron un proxy de API que intercepta las llamadas de los agentes y produce artefactos normalizados denominados token — usage.jsonl.
Cada registro del token — usage.jsonl incluye tokens de entrada y salida, tokens leídos y escritos en caché, modelo, proveedor y marcas temporales. Esa estructura permitió combinar las métricas de uso con los logs de workflow existentes y reconstruir el historial de consumo por ejecución y por paso. Con datos homogéneos pudieron medir no solo el total de tokens usados, sino también el desglose por fuente: consultas al modelo, lecturas de caché y efectos de herramientas declaradas en los manfiestos de los agentes.
Antes de esta instrumentación el equipo chocaba con la heterogeneidad de formatos entre frameworks de agente: Claude CLI, Copilot CLI y Codex CLI emitían logs distintos y, en muchos casos, los datos históricos eran incompletos. Esta falta de estandarización impedía detectar con regularidad cuándo un cambio en el código o en la configuración de herramientas había provocado un pico de consumo. Al normalizar los artefactos de uso pudieron aplicar reglas sistemáticas de análisis y automatizar auditorías diarias.
Con las métricas en mano desarrollaron dos flujos de optimización que se ejecutan cada día: el Daily Token Usage Auditor y el Daily Token Optimizer. El Auditor agrega consumo por workflow, identifica incrementos significativos y marca anomalías — por ejemplo, pases que normalmente requieren cuatro interacciones y pasan a 18—, lo que facilita priorizar investigaciones. El Optimizer, por su parte, analiza el código y los logs recientes para proponer cambios concretos y, cuando procede, abre issues en GitHub con recomendaciones reproducibles para los mantenedores del repositorio.
El Auditor detecta patrones de consumo atípicos mediante agregaciones temporales y reglas de «alerta por salto» que señalan desviaciones respecto a la mediana histórica. Esto pone en foco ejecuciones que, aunque infrecuentes, pueden inflar las facturas si ocurren en testing automatizado. El Optimizer completa el ciclo: a partir de las trazas identifica el origen técnico de la desviación — por ejemplo, un paso que reintenta demasiadas veces o una herramienta que envía esquemas innecesarios— y propone cambios concretos que pueden aplicarse como parches o sugerencias en issues.
Un hallazgo recurrente fue la sobrecarga por registros de herramientas MCP que no se usan efectivamente en los turnos del agente. Los runtimes de agente suelen incluir nombres de funciones y esquemas JSON de herramientas en cada petición; en un servidor MCP con 40 herramientas esto puede añadir entre 10 y 15 KB de esquema por turno. Cuando el agente realmente emplea solo dos herramientas, las restantes representan una sobrecarga en cada llamada al modelo y, por tanto, un consumo extra de tokens en el contexto.
La herramienta Optimizer identifica esas discrepancias cotejando los manifiestos de herramientas con las llamadas reales observadas en los logs. Cuando detecta herramientas definidas pero sin uso propone podarlas de la configuración del agente. En pruebas de humo, eliminar herramientas no usadas redujo el tamaño del contexto por llamada entre 8 y 12 KB, lo que se tradujo en un ahorro de varios miles de tokens por ejecución sin alterar el comportamiento funcional del workflow durante las pruebas.
Además de podar herramientas, el equipo encontró que sustituir llamadas MCP para tareas de obtención de datos por comandos del GitHub CLI ofrecía un ahorro mayor. Una llamada MCP implica un paso adicional de razonamiento y el intercambio de JSON de herramientas, argumentos y respuestas — es decir, más entradas al LLM—, mientras que ejecutar gh pr diff o comandos equivalentes es una petición determinista HTTP a la API de GitHub que no consume tokens del modelo.
Para aplicar esa sustitución emplearon dos tácticas complementarias: descargas previas al agente y un proxy CLI dentro del agente. En el primer caso, pasos de preparación ejecutan comandos gh antes de lanzar el agente y escriben los resultados en archivos del workspace que el agente lee localmente. Cuando la descarga previa no es viable, usan un proxy HTTP transparente que permite al agente ejecutar comandos como gh pr view-json y obtener datos estructurados sin exponer credenciales ni añadir llamadas al LLM.
Las medidas iniciales generan ya un ciclo virtuoso aunque con coste propio: los propios Auditor y Optimizer consumen tokens porque analizan logs y ejecutan modelos, pero identifican ineficiencias que devuelven un ahorro neto mayor. Al combinar instrumentación con cambios de arquitectura — poda de herramientas, uso de gh para obtener datos y proxys que evitan tráfico LLM-GitHub reporta resultados preliminares reproducibles entre sus repositorios. El equipo propone estas prácticas como un conjunto aplicable a otros equipos que gestionan agentic workflows y necesitan controlar costes de CI sin sacrificar automatización.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
