RTK promete ahorros de tokens, pero nuestros benchmarks de costos no coinciden
RTK reports token savings, but our cost benchmarks disagree
RTK, con más de 79k estrellas en GitHub, comprime la salida de terminal antes de que el agente de IA la lea. Sin embargo, tras gastar más de $1,500 en tokens en Terminal-Bench 2.1, encontramos que los ahorros reportados no se traducen en facturas más bajas. En Claude Code con Fable 5.0, el ahorro dependió de una sola tarea; en OpenCode con DeepSeek V4 Pro 0813, el costo por tarea subió 17% en promedio. La métrica 'rtk gain' cuenta bytes eliminados, no dinero ahorrado, y puede hacer que un intento más caro parezca optimizado.
RTK reduce hasta un 90% de la salida de bash que lee tu agente. […] no es lo mismo que reducir tu factura en un 90%.
- aeneas_ory
Todos estos "hacks" son puro snake oil y creo que en el fondo todos lo sabemos. Ya sea caveman, RTK o cualquier otro hack/skill/claude.md de productividad o ahorro de tokens vibe-codeado.
Lo que a mí sí me funcionó (aunque los benchmarks son más viejos) es indexar el codebase con un modelo de embeddings de código local dedicado. Es un poco caro del lado de la CPU, pero en mis benchmarks redujo el uso de tokens y el tiempo de reloj de forma significativa. Claro, siempre depende del ruido estadístico + la carga del sistema anfitrión, y correr benchmarks lo bastante grandes es simplemente demasiado caro, así que tómalo con pinzas.
¿Por qué funciona, te preguntarás? Bueno, los LLMs básicamente fuerzan palabras/frases a lo bruto y las canalizan hacia find/grep/pgrep/lo que sea (o, como se discutió recientemente por aquí, escriben un script de python para eso - https://news.ycombinator.com/item?id=49654229). La búsqueda semántica busca similitudes, así que tienes que forzar menos a lo bruto. Eso sí, a costa de indexar todo primero.
Puedes encontrar el proyecto aquí: https://github.com/ory/lumen
- ProjectBarks
Parece que la mayoría de estas herramientas son más que nada vaporware. Los benchmarks hechos sobre Headroom y RTK muestran que ninguna de las dos produce ahorros reales. Si fuera posible tener un paso de preprocesamiento tan simple, ¿por qué los AI Labs no subirían esas optimizaciones ellos mismos al upstream?
Mi conjetura es que en su mayoría no funcionan o vuelven el comportamiento mucho más confuso para el modelo. Realmente creo que hace falta algún tipo de benchmark independiente.
Aquí hay otros casos que demuestran exactamente los mismos problemas con este tipo de herramientas:
https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-...
https://brandonbarker.me/writing/headroom-fewer-tokens-bigge...
- oefrha
Es bastante obvio para cualquiera que se haya molestado en mirar la salida de rtk gain, no hace falta ningún benchmark. El agente ejecuta
rtk command-that-prints-100k-tokens | tail -5
cuesta 5 líneas, quizá 100 tokens sin rtk, pero rtk reportará 100k de ahorro. Claro, no tiene ni idea de ese tail -5.
Peor aún, como rtk por defecto persiste esa estadística de ahorro, rompe el sandboxing. Ponerle el prefijo rtk también lleva a denegaciones aleatorias del modo automático de vez en cuando (esto es independiente de desactivar la persistencia de la estadística de ahorro).
Honestamente no tengo idea de por qué alguien que sepa lo más mínimo de CLIs se tomaría en serio rtk gain. ¿Supongo que los vibe coders despistados que casi nunca han trabajado en una terminal mirarán la estadística y se sentirán bien al respecto?
Dicho esto, rtk sigue siendo algo útil para comprimir salidas repetidas de ejecuciones de tests y esas cosas, pero solo deberías usarlo con comandos en lista blanca; envolverlo todo como te sugieren es simplemente estúpido.
- kriskrunch
Pregunta abierta, ¿qué tal se ve esta instrucción en agent-rules.md?
"Limita la salida de comandos grandes/desconocidos: `COMMAND 2>&1 | head -c 4000`. Nunca transmitas logs completos, tests o archivos grandes."
Uso eso en lugar de RTK. Empíricamente, encontré que RTK hace que mis agentes tarden más en completar tareas similares.
Ponytail y Caveman parecen ayudar algo.
- stephantul
Creo que cualquiera que sea aunque sea un poco realista sabe que la mayoría de las tecnologías exageran sus afirmaciones, o las evalúan en condiciones muy favorables.
Esto no es algo bueno, por supuesto, pero también siento que hacerse el sorprendido de que esto pase es un poco innecesario.
Dicho esto: la mayoría de las herramientas no son útiles