La ilusión de la compresión de tokens: por qué soy escéptico con RTK

• RTK promete reducir costos comprimiendo la salida de terminal de los agentes de código, pero reducir la salida bruta no significa automáticamente una ingeniería de software más barata, segura y precisa
• El “ahorro de 60–90%” no significa que la facturación del LLM haya bajado en esa misma proporción, sino que se acerca más al porcentaje de salida de línea de comandos que RTK eliminó
• Si aparecen silent failures donde la salida de terminal se corrompe o se omite silenciosamente, el agente puede tomar malas decisiones sin trazas de pila ni contexto del compilador importantes
• Las gráficas de ahorro de tokens por sí solas no bastan; hacen falta la tasa de éxito de tareas y evaluaciones de precisión estilo SWE-bench para mostrar si un agente autónomo realmente completó el trabajo
• RTK parece más una función de herramienta de desarrollo que un producto independiente, y como es vulnerable a cambios en la salida de CLI como git, cargo, npm y grep, implica un alto riesgo operativo para ponerlo en la ruta crítica de agentes en producción

---

La estructura de costos real que ocultan las cifras de ahorro

• RTK promueve la reducción del uso de tokens y la baja de costos mediante compresión de salida de terminal para agentes de código
  • Ha conseguido más de 60k estrellas en GitHub y la industria está reaccionando con fuerza a esa promoción
  • Aun así, las afirmaciones de herramientas para desarrolladores que “suenan demasiado bien” deben examinarse en su estructura real
• La cifra viral de “60–90% de ahorro” no equivale a un ahorro real en la facturación de la API
  • Lo que RTK reduce es una parte de la salida de Bash
  • Siguen existiendo factores de costo mayores, como lecturas profundas de archivos, contexto del repositorio, prompts del sistema y tokens de razonamiento interno del modelo
  • Comandos como rtk gain parecen más orientados a métricas que lucen bien en capturas para redes sociales o ante gerentes no técnicos que a una optimización arquitectónica de fondo
  • Incluso en issues recientes de GitHub ya empezaron a señalarse problemas con métricas exageradas

La precisión y la estabilidad operativa son variables más importantes

• La optimización no sirve de mucho si no viene acompañada de precisión, y en los issues públicos del repositorio ya aparecen casos donde la salida de terminal se rompe u omite silenciosamente
  • El riesgo central es que el agente de IA no sabe que el texto fue comprimido
  • Si RTK elimina líneas importantes de una traza de pila o del contexto del compilador para ahorrar unos cuantos tokens, tanto el usuario como el LLM terminan trabajando con información incompleta
  • Adoptar RTK significa depender de una capa externa que debe parsear, interpretar y resumir la salida de innumerables herramientas CLI sin perder significado
• RTK muestra gráficas de ahorro de tokens, pero falta la métrica que realmente importa: la tasa de éxito de tareas
  • Lo clave es si el agente autónomo resolvió el problema de ingeniería de software al final de su bucle de ejecución
  • Aunque el costo del prompt baje 80%, si por pérdida de contexto el agente alucina, falla en el build o se queda en loop, al final puede terminar consumiendo más tokens
  • Hasta que no haya evaluaciones rigurosas de precisión estilo SWE-bench junto con las gráficas de costo, la narrativa de RTK sigue incompleta
• Desde una perspectiva de arquitectura, RTK añade una dependencia externa vulnerable en la ruta crítica síncrona entre el agente y el shell
  • La optimización de salida se parece más a una función que a un producto o plataforma independiente
  • Si los principales CLI y herramientas de desarrollo ofrecen flags nativos como --compact o --json-stream pensados para consumo por LLM, la principal ventaja de RTK podría desaparecer
• RTK depende fuertemente de parsear formatos de stdout/stderr pensados para humanos, lo que lo vuelve difícil de mantener
  • Si git, cargo, npm o grep cambian unos cuantos espacios del formato de terminal o el layout de errores, las expresiones regulares y filtros de parsing de RTK pueden romperse
  • En ese caso podría fallar silenciosamente en lugar de dar un error explícito, entregando al agente texto corrupto o parcial
• RTK intercambia confiabilidad determinista, integridad semántica y simplicidad arquitectónica por una métrica vistosa de reducción de tokens de terminal en bruto
  • Hasta que resuelva la degradación silenciosa y ofrezca benchmarks transparentes de precisión de tareas, ponerlo en la ruta crítica de flujos de trabajo de agentes en producción implica un riesgo operativo alto en comparación con el descuento ofrecido

[GN⁺]

Opiniones en Hacker News

• Da gusto que este tipo de textos por fin empiecen a ganar fuerza respecto a toda la industria de la caja mágica de los LLM
  Desde caveman mode hasta RTK y la búsqueda semántica, da la impresión de que los desarrolladores se volvieron más magos recitando conjuros que ingenieros, y en el trabajo cansa especialmente que cada quien esté convencido de que su propio conjuro es la técnica definitiva para ahorrar tokens
  Mi criterio es este: las ideas que no están dentro de un evaluation harness por lo general no valen mucho, y las ideas buenas terminan llegando a Codex/Claude. También cuesta creer esos anuncios en GitHub de que ahorran cierto porcentaje de tokens
  En este campo es difícil evitar herramientas medio fraudulentas, y ojalá la gente empiece a verlas con más sentido crítico

  • Está completamente equivocado, y está subestimando lo incompetentes que son las empresas de punta en todo lo que no sea crear modelos LLM
    Durante un año también hubo casos como TUIs parpadeantes “escritas como si fueran motores de juego”, y al correr yo mismo varios benchmarks vi que sí hay métodos validados para reducir tokens manteniendo el mismo resultado. Por ejemplo, encontrar el mismo CVE o detectar el mismo bug en una revisión de código
    Puede ver una pequeña demostración mía en https://maki.sh
  • Por eso hago pruebas A/B a ciegas para todo
    Se queman muchos tokens, pero hay que demostrar que de verdad aporta valor, y la mayoría no alcanza ni de cerca ese estándar
    Mi agente de IA también tiene varias funciones, pero no considero que los resultados de una prueba A/B a ciegas de hace 4 meses sigan siendo válidos hoy. Incluso la elección de palabras que uso puede cambiar mucho los resultados
    Aun así, hago pruebas para confirmar el valor por mí mismo y verlo con mis propios ojos. No publico resultados concretos de esas pruebas A/B a ciegas
    También he visto a otras personas hacer muy mal las pruebas A/B a ciegas, y si la medición es deficiente, la prueba en sí no significa nada
    Todos estamos resolviendo este problema juntos, hay mucha magia negra y por eso dependo bastante de hooks. Mi pequeño agente de IA seguramente también está lleno de magia negra
    Lo único que sé con certeza es que a mí me funciona. Si no usara esto, honestamente no sé cómo trabaja la gente con IA hoy en día
    Dejo el enlace, pero no significa que te lo recomiende hagas lo que hagas. Casi solo lo usan otros ingenieros de software y está muy especializado para lo que yo necesito hacer. Con suerte, puede darte ideas para implementarlas tú mismo
    https://github.com/notque/vexjoy-agent
  • Decir que “las buenas ideas llegan a Codex/Claude” solo se cumple cuando alguien crea herramientas como RTK y otros las prueban
    Está bien limitarse a observar esta ronda, pero herramientas como RTK, Headroom y caveman mode pueden reducir los tokens de entrada y salida que hay que procesar, y en LLM locales pueden producir mejoras de velocidad medibles
    No hay suficientes datos para decir si perjudican la calidad del resultado final, pero es divertido trastear con ellas para averiguarlo
  • La idea en sí es razonable. Si se puede reducir la relación señal-ruido de la ventana de contexto, eso es algo bueno
    Lo que todavía no se ha demostrado es si RTK realmente hace eso. Me gustaría ver benchmarks serios sobre la diferencia real que genera esta herramienta, no frases vacías como “hasta un 90%”
  • Yendo más allá, algunas de las optimizaciones que vi en rtk para comandos como git status ya parecen haber subido a la capa del modelo
    Codex ahora suele hacer llamadas a herramientas como git status --short en lugar de git status

• Soy el autor del texto. Siendo sincero, lo escribí porque como ingeniero de software rtk ai me parecía muy raro
  Me molestó la falta de cifras, la ausencia de menciones a la precisión y la forma en que la gerencia impulsa esto para optimizar costos. Ahora la gente envuelve con rtk todos los comandos que puede, intenta manejar todos los comandos importantes y hasta decidir qué salida debería recibirse

  • De verdad me gustaría escuchar opiniones sobre https://www.github.com/jahala/tilth
    Es un enfoque distinto a RTK y lo hemos benchmarkeado con una reducción de aproximadamente 40% en el costo por respuesta correcta
  • No entiendo por qué no presentó ni una sola métrica de uso real para respaldar sus afirmaciones. No ayudó mucho

• La salida de herramientas ocupa una parte grande de mi salida. Si pudiera ahorrar 3.7 millones de tokens de 3.9 millones de tokens de entrada, lo aceptaría. Un token ahorrado es un token ahorrado
  Como usuario de RTK, estaría bueno tener benchmarks de precisión, pero todavía no he visto evidencia de que el modelo se haya perdido algo importante por la compresión
  Por filosofía de diseño, la preservación de la precisión se trata con muchísimo rigor, hasta el punto de volver a la salida original si falla un filtro. También revisé directamente el código fuente de varios comandos usados con frecuencia, me gustó lo que vi, y hasta ahora diría que se ha ganado mi confianza
  También existe la preocupación de que, si git, cargo, npm o grep cambian unas cuantas columnas del formato de terminal o el diseño de los errores, los regex y parsers de RTK se rompan, pero si el filtro falla, vuelve a la salida original. RTK es una herramienta diseñada para no alimentar al agente con texto dañado o parcial
  La preocupación es válida, pero me gustaría que la crítica estuviera respaldada por evidencia. Me pregunto si lo han usado y si encontraron pruebas de que no preserva la precisión

  • Lo vi mientras investigaba el tema, y varios issues que saltaron a la vista se ven bastante mal
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • A veces un token ahorrado no es un token ahorrado
    RTK elimina flags y otra información. A veces eso hace que después se gasten más tokens para recuperarla. Aunque hayas ahorrado 70% de tokens en esa llamada de herramienta, las métricas no muestran si en vez de 1 llamada de herramienta terminaste haciendo 3
    También habría que considerar si la salida eliminada hace que se gasten más tokens de razonamiento
  • No creo que alcance con decir que preserva la precisión de forma muy estricta
    Si consideras la diferencia de costo entre modelos de última generación y modelos open weight rezagados, o entre el modelo más grande y el que le sigue, el rendimiento debe medirse con muchísimo cuidado
    Más que pedirle pruebas a quien critica, RTK debería demostrar que no degrada el rendimiento

• El punto es que hay una cantidad enorme de herramientas que supuestamente mejoran la IA, pero no hay una forma de medir si la IA realmente funciona mejor
  Las grandes empresas con productos populares sí tienen una forma. En algún punto entre la analítica de producto tradicional y la evaluación de chatbots, determinan si el usuario está teniendo éxito en una sesión. Ese es el trabajo
  Pero un desarrollador individual que corre entre 3 y 50 sesiones al día casi no tiene forma de saber qué hace mejor al LLM. Todo es por intuición
  En nuestra empresa tenemos todo el stack: harness preferido, modelo, skills e incluso estructura de código. Debería haber una forma de medir si esta configuración nos funciona, incluso a una escala de una millonésima de Claude Code

  • En mi producto, explícitamente le digo al agente que pregunte. Hay ejemplos reales y repositorios reales con los que puedes probarlo
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    No me importa tanto el ahorro promedio de tokens. Me interesa más si la IA evita meter archivos innecesarios al contexto, porque eso sí puede afectar el razonamiento
    Después de la tarea, basta con preguntarle al agente: “¿Cuántos archivos crees que no habrías leído si antes hubieras sabido para qué servían?”
  • El esfuerzo necesario para crear un benchmark válido es enorme. Probablemente sea cierto, y por eso mismo es más frustrante
    Ya había muchísima discusión incluso con frameworks establecidos, y esto es mucho peor. Termina siendo una pelea de mi intuición contra tu intuición. Quién iba a pensar que una salida no determinista nos traería hasta aquí
  • Sí hay una respuesta. Este tipo de herramientas debería medirse no por simple ahorro de tokens, sino por costo por respuesta correcta

• Lo usé personalmente, y no comprime los mensajes que ocupan el 90% de mi contexto, así que solo comprimió una parte pequeña del uso total de tokens
  Si lees el post con cuidado, eso mismo dice claramente. Si ves /context, probablemente notes que donde se consumen tokens no es en las llamadas de herramientas. Por eso, un proxy que solo comprime llamadas de herramientas no puede tener un impacto grande, incluso si fuera cierto que comprime esas llamadas 8x
  En sesiones largas de programación no fue algo muy importante para mí
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Este post casi no tiene datos que respalden el argumento contrario, y en su mayor parte se lee como texto generado por un LLM

• En Semble también hemos recibido esta queja. Me parece una queja válida, pero crear este tipo de benchmark es muy difícil y caro por la combinación harness × modelo × MCP/CLI
  En machine learning tradicional o en herramientas clásicas, no mostrar benchmarks solía ser una señal de alerta. Pero en herramientas para LLM, no estoy tan seguro

• Si haces que el agente sea consciente de la compresión de RTK y le das una opción para saltársela, sí hay una forma de hacer que detecte truncamientos. Yo uso RTK_DISABLE=1 para restaurar el texto completo original
  Funciona bien, y sí. Como solo comprime la salida de comandos, desde la perspectiva de la “compresión” solo afecta los tokens de entrada

• Es cierto que los CLI y las herramientas de desarrollo más usadas podrían ofrecer flags nativos como --compact o --json-stream pensados para consumo por LLM, pero no lo van a hacer pronto
  Por eso herramientas como rtk, caveman y ponytail siguen intentando reducir costos que no dejan de crecer. En una organización de 2,000 personas, hoy estamos hablando de alrededor de 2.5 millones de dólares, y todos estamos al tanto de estos trade-offs y ajustándolos
  A diferencia de lo que afirma el autor, sí conocemos bien esos trade-offs, y usamos estas herramientas bifurcando herramientas, haciendo benchmarks y validando si la calidad de salida se ajusta a nuestras necesidades. No las usamos a ciegas
  Para un desarrollador individual quizá no sea estrictamente necesario, y puede que sea mejor autoalojar otro modelo para ahorrar costos. Pero en organizaciones es un tema bastante fuerte
  Está bien que este tipo de posts arrojen luz sobre el tema, pero igual que con las herramientas, también hay que leer este tipo de textos con cierto filtro

• Probé rtk gain en Mac. Reinstalé mi máquina principal de desarrollo por problemas de memoria y quedaron algunas cosas desconfiguradas, así que no pude verificarlo ahí, pero en Mac redujo aproximadamente 51 mil tokens de entrada y 23 mil tokens de salida, y ahorró en promedio 3 segundos por comando
  No entiendo bien por qué tanta rabia ni por qué hacía falta escribir todo un post por esto
  No sé quién le pasa trazas de pila a RTK por pipe. Yo solo lo uso con un programa muy específico, y meterle la salida del compilador me parece una tontería. Basta con indicarle al agente que use RTK solo para un conjunto específico de comandos