AgentDiet: cómo reducir un 60% los tokens de tus coding agents sin perder calidad
TL;DR
- Los coding agents (Cursor, OpenClaw, Claude Code) acumulan contexto basura en cada iteración: errores corregidos, imports innecesarios, fragments descartados
- AgentDiet elimina automáticamente esas trayectorias redundantes antes de cada llamada al LLM
- Resultados: reducción de input tokens del 39.9-59.7% y del coste computacional total del 21.1-35.9%, sin pérdida de rendimiento
- Es un enfoque complementario a la compresión de prompts: actúa sobre lo que el agente ya hizo, no sobre lo que le pides
Contexto
Si usas coding agents en tu día a día, ya sabes que la factura de API puede doler. Un agente que resuelve un bug en 8 iteraciones está enviando no solo tu prompt original, sino todo el contexto acumulado: los errores que corrigió, los imports que añadió y luego quitó, los fragments de código que probó y descartó. Eso se suma rápido.
El paper “Reducing Cost of LLM Agents with Trajectory Reduction” (aceptado en FSE 2026) cuantifica este problema y propone una solución elegante. La pregunta clave: ¿cuánto de ese contexto acumulado es realmente necesario para que el agente siga funcionando bien?
Spoiler: bastante menos de lo que piensas.
El problema: trayectorias infladas
Cuando un coding agent ejecuta una tarea, genera una secuencia de pasos (trayectoria). Cada paso incluye:
- El estado del código antes de la acción
- La acción tomada (editar fichero, ejecutar test, etc.)
- El resultado/feedback
El problema es que estas trayectorias contienen mucho “ruido”:
- Errores que ya se corrigieron en pasos posteriores
- Código que se añadió y luego se eliminó
- Información de debugging que ya no es relevante
- Output de tests fallidos que luego pasaron
Los autores encontraron que entre el 40% y el 60% de los tokens de input en cada llamada eran este tipo de información redundante. Y no estamos hablando de modelos baratos: cuando usas GPT-5.5 o Claude Opus 4.7 como backend, cada token cuenta.
Cómo funciona AgentDiet
El enfoque es sorprendentemente simple en su concepto:
- Análisis de dependencia: Después de cada paso del agente, AgentDiet analiza qué partes de la trayectoria anterior son necesarias para los pasos futuros
- Reducción de trayectoria: Elimina los pasos que no aportan información útil para la decisión actual
- Preservación de contexto crítico: Mantiene los pasos que contienen decisiones irreversibles, errores que afectan al contexto actual, o resultados de tests relevantes
La implementación se hace como un wrapper alrededor del agente, interceptando las llamadas al LLM y reduciendo el contexto antes de enviarlo. No requiere cambios en el modelo ni en el agente本身.
Los números
Los autores evaluaron AgentDiet en dos LLMs (uno open-source y uno comercial) y dos benchmarks de coding (SWE-Bench y HumanEval). Estos son los resultados:
| Métrica | Reducción |
|---|---|
| Input tokens | 39.9% - 59.7% |
| Coste computacional total | 21.1% - 35.9% |
| Tasa de éxito (resolución de tareas) | Sin cambio estadísticamente significativo |
La reducción de coste total es menor que la de tokens porque el agente sigue generando el mismo output (los tokens de output no cambian). Pero en términos de input tokens — que es lo que pagas cuando usas modelos frontier — la diferencia es brutal.
Para ponerlo en contexto: si tu coding agent cuesta $50/día en API calls, AgentDiet podría reducirlo a $20-30/día. A escala de un equipo de 10 developers, eso son $600-900/mes de ahorro.
¿Qué significa para ti?
Si usas coding agents (Cursor, Claude Code, OpenClaw)
AgentDiet aún no está integrado en estas herramientas, pero el paper demuestra un punto importante: parte significativa de lo que pagas es “basura” contextual. Mientras las herramientas lo integren, puedes mitigar esto manualmente:
- Reinicia la conversación del agente cuando cambias de tarea
- No dejes que el agente acumule contexto de bugs resueltos
- Usa ventanas de contexto más cortas cuando sea posible
Si construyes agentes propios
El paper es directamente aplicable. El approach de reducción de trayectoria es relativamente sencillo de implementar como middleware. Los autores publicaron el artefacto en Figshare con el código.
Complementa, no reemplaza
AgentDiet no compite con técnicas como Pith (compresión de prompts) o el routing entre modelos. Son capas diferentes:
- Routing: elige el modelo adecuado para cada tarea
- Compresión de prompts: reduce lo que le pides
- AgentDiet: reduce lo que el agente ya hizo pero ya no necesitas
Combinadas, las tres pueden reducir costes un 70-80%.
Metodología del paper
Para los que quieran profundizar:
- Benchmarks: SWE-Bench Verified y HumanEval
- Modelos: dos LLMs (uno open-source, uno comercial — los autores no revelan cuáles exactamente)
- Agente base: SWE-Agent, modificado con AgentDiet como wrapper
- Métricas: input tokens, coste computacional (FLOPs), tasa de resolución de tareas
- Paper: arxiv.org/abs/2509.23586
- Aceptado en: FSE 2026 (ACM International Conference on the Foundations of Software Engineering)
Conclusión
AgentDiet es uno de esos papers que te hace decir “¿cómo no se nos ocurrió antes?”. El problema es obvio una vez que lo ves: los coding agents acumulan basura contextual como un Haus virtual. La solución es igual de obvia: limpia lo que no necesitas antes de cada llamada.
El ahorro del 40-60% en input tokens sin perder rendimiento es un resultado sólido. Si estás pagando por agents que iteran múltiples veces sobre código, esto debería interesarte. Y si estás construyendo agentes, deberías estar pensando en implementar algo similar.
El código está disponible. Los números son replicables. No hay excusa para seguir pagando por tokens basura.
Fuentes: AgentDiet paper (arXiv:2509.23586), FSE 2026 acceptance, Artifact en Figshare