Menos tokens por llamada no es lo mismo que menos coste real

Cuando un equipo empieza a preocuparse por lo que le cuesta un agente de IA, el primer instinto es casi siempre el mismo: acortar. Recortar el output de cada comando, resumir cada respuesta, minificar cada prompt. Si cada llamada individual pesa menos tokens, la factura total tiene que bajar. Es una intuición razonable — y, según lo que documentó recientemente el equipo de ingeniería de GitHub Copilot, también incompleta.

En su análisis, publicado el 2 de septiembre de 2026 por Erik Kristensen y Napalys Klicius, cuentan cómo probaron una herramienta externa (RTK, "Rust Token Killer") pensada exactamente para eso: comprimir el output de shell antes de que el agente lo lea. El resultado fue contraintuitivo: cada llamada individual sí pesaba menos, pero la tarea completa terminaba costando más. El motivo es el que da título a este artículo — y el que, trasladado a cómo diseñamos reglas y skills en Spec-Driven Development, cambia bastante la forma de pensar la "economía del token".

Cuando RTK omitía información que el modelo sí necesitaba, el agente no se quedaba con la versión incompleta: reabría el output original o volvía a ejecutar el comando para recuperar lo que faltaba. Esa recuperación añadía turnos completos, y cada turno vuelve a arrastrar todo el contexto de la sesión hacia delante. La llamada suelta pesaba menos; la tarea, de principio a fin, pesaba más. Ahorraron tokens en local y gastaron más en global.

La respuesta de GitHub no fue abandonar la compresión, sino cambiar la pregunta: en vez de "¿cómo hago más corta esta respuesta?", pasaron a "¿qué puedo quitar sin que el modelo tenga que repetir trabajo?". De ahí salió una política de tres reglas, validada con benchmarks agénticos y con repositorios open source reales antes de tocar producción:

• Output tipo fuente (cat, git diff, git show, scripts arbitrarios) se devuelve tal cual, sin tocar.
• Resultados de búsqueda (grep y similares) se reorganizan de forma más eficiente, pero sin perder ni una coincidencia.
• Solo el ruido repetitivo y predecible — logs de install, build, test, lint — se comprime, y únicamente cuando el ahorro es sustancial.

Además de eso, dejaron una vía de recuperación explícita para el original completo, y la usaron como señal de calidad: si el agente recurría a ella con frecuencia, era la prueba de que se había comprimido algo que sí importaba. En sus benchmarks, esa vía de recuperación se usó rarísimas veces — la señal de que la compresión final era, por fin, segura.

Lo más honesto del artículo original es que no presenta un único cambio milagroso, sino cuatro experimentos A/B independientes, cada uno evaluado primero offline (benchmarks agénticos) y después en producción real con usuarios de GitHub Copilot CLI. El ahorro de cada uno, medido en su propia métrica de "AI Credits":

El caso de la compactación del prompt de su "task tool" (el orquestador que lanza subagentes en paralelo) es el más instructivo. Usaron un bucle de meta-prompting en el que el propio modelo reescribía su prompt hasta reducirlo casi a la mitad. El primer experimento online detectó una regresión que la evaluación offline no había capturado: la reescritura había convertido una guía cautelosa de paralelismo en una política de scheduling rígida, y agentes independientes que debían ejecutarse en paralelo pasaron a ejecutarse en serie — más lento y más caro, aunque el prompt fuera más corto. Pararon el experimento, escribieron un test de regresión para ese comportamiento concreto, y la solución final sustituyó una lista explícita de permisos y bloqueos por una sola frase: "Los agentes independientes pueden ejecutarse en paralelo; ten en cuenta los efectos secundarios." Más corta, menos rígida, y deja la decisión al propio modelo en vez de micro-gestionarla.

El caso de GitHub trata sobre el harness de un producto, pero el principio se aplica igual de directo a cómo un equipo diseña su propio contexto en Spec-Driven Development. Un CLAUDE.md, una skill o una regla que se "minifica" para ahorrar ventana de contexto tiene exactamente el mismo riesgo que RTK: si le quita al agente la referencia que necesitaba —el patrón de arquitectura, el formato exacto de un contrato OpenAPI, el criterio de aceptación de borde—, el agente no se queda callado. Vuelve a explorar el repositorio, vuelve a preguntar, o directamente decide por su cuenta y se equivoca. El coste no desaparece: se traslada a la siguiente iteración, con más turnos y más contexto arrastrado que si la regla hubiera sido explícita desde el principio.

La métrica correcta, igual que en el caso de GitHub, nunca es el tamaño de un archivo de contexto suelto. Es la tarea completa: desde que se enriquece un ticket hasta que el código pasa la validación humana. Y el mismo mecanismo de seguridad que usó GitHub —una vía de recuperación explícita, medida como señal de calidad— tiene su equivalente en SDD: si un agente reabre constantemente documentación "ya resumida" o repite exploración que una regla debería haberle ahorrado, esa regla es la que hay que revisar, no el prompt que la invoca.