RTK: cómo reducir tokens en agentes de IA sin quedarte ciego al depurar

RTK ataca un problema muy concreto: los agentes de coding mandan demasiada salida de terminal al modelo y eso cuesta dinero.

Cuando usas un agente de código, no pagas solo por el prompt bonito que escribes. Pagas por el contexto que entra y la respuesta que sale. Si el agente ejecuta tests, imprime logs enormes, lee diffs completos o lista directorios gigantes, una parte importante del coste está en texto que nadie necesitaba leer entero.

Qué tipo de ruido recorta

• Trazas largas donde solo importan las primeras y últimas líneas.
• Logs repetidos de frameworks que no explican el fallo.
• Salidas de comandos con cientos de archivos irrelevantes.
• Diffs donde el agente necesita contexto localizado, no todo el patch.
• Mensajes de instalación o build que repiten warnings conocidos.

Workflow recomendado

• Empieza con comandos ruidosos pero no críticos: logs de desarrollo, listados largos o salidas de tests conocidas.
• Compara una sesión normal con una sesión usando RTK.
• Mide si el agente pide menos contexto adicional después del resumen.
• Mantén una vía para ver la salida completa cuando el bug sea ambiguo.
• No lo metas primero en producción o CI crítico; úsalo antes en sesiones interactivas.

Dónde puede ahorrar de verdad

• Equipos que usan agentes todos los días y pagan por API.
• Repos con suites de test grandes y salidas verbosas.
• Workflows de code review donde el agente lee demasiados diffs.
• Sesiones largas de depuración donde el modelo acumula contexto sin limpiar.

Relación con observabilidad

RTK no arregla logs malos. Si tu aplicación imprime mensajes ambiguos, el resumen será ambiguo. Antes de optimizar tokens, conviene mejorar errores: códigos claros, mensajes específicos, rutas de archivo y contexto mínimo.

Los equipos que más se benefician de herramientas así suelen ser los que ya tienen buenos tests y logs. La compactación funciona mejor cuando la señal original existe.