RTK recorta tokens, pero no abarata la codificación con IA

RTK promete recortes de hasta el 90%, pero los benchmarks cuentan otra historia

RTK (Rust Token Killer) se ha convertido en una de las herramientas más comentadas para abaratar la codificación con agentes de IA: ya suma más de 79.000 estrellas en GitHub y un post viral en X asegura que recorta hasta un 60% los tokens de Claude Code (313.000 vistas). Sin embargo, un nuevo benchmark independiente de Quesma, basado en más de 1.500 dólares gastados en tokens y 1.740 intentos sobre tareas reales, llega a una conclusión incómoda: RTK no abarata la codificación agentiva de forma generalizada, y en algunos modelos incluso la encarece.

¿Qué hace exactamente RTK y por qué se viralizó?

RTK actúa como un filtro entre el agente y la terminal: intercepta comandos como git, ls, find o npm y devuelve una versión comprimida del resultado. Por ejemplo, convierte la salida de ls -la (con propietario, fecha y permisos) en una línea minimalista con los permisos octales (644) y el tamaño en bytes.

Su métrica estrella es rtk gain: los bytes eliminados divididos por 4, interpretados como «tokens ahorrados». En los benchmarks del propio repositorio, la herramienta reporta ahorros del 89% en 445 intentos con DeepSeek. El problema es que esa métrica mide bytes eliminados, no dinero ahorrado — y ahí empieza el desajuste.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El propio README incluye una advertencia explícita: «RTK cuts up to 90% of the bash output your agent reads […] it is not the same as cutting your bill by 90%». Es decir, menos texto en la terminal no significa necesariamente una factura más baja.

Qué midió Quesma: 1.740 intentos sobre Terminal-Bench 2.1

Quesma ejecutó su prueba sobre Terminal-Bench 2.1, un benchmark con fuerte interacción por terminal. La elección no es casual: en las versiones 3.0 y 4.0 los agentes suspenden casi todo, así que solo en 2.1 el coste tiene sentido como variable a optimizar (solo importa cuánto cuesta lo que funciona).

Setup del experimento:

Claude Code 2.1.220 con el modelo Fable 5.0 de Anthropic
OpenCode 1.18.25 con DeepSeek V4 Pro 0813 (vía OpenRouter)
Cada tarea corrió 5 veces sin RTK y 5 veces con RTK, mismo modelo, mismo timeout
Después de eliminar 4 tareas de seguridad de Fable con rechazos: 85 tareas de Fable y 89 de DeepSeek
Total: 1.740 intentos

Los resultados: ahorro mínimo con Fable, subida clara con DeepSeek

Los números de Quesma desmontan la promesa viral:

Costes con RTK: cayeron un 5% con Fable y subieron un 5% con DeepSeek.
Tasa de acierto: bajó un 1% con Fable y un 2% con DeepSeek (diferencias pequeñas, pero en contra).
Coste por tarea que pasa (incluyendo intentos fallidos): Fable fue un 3% más barato, DeepSeek un 7% más caro.
Media ponderada por tarea: Fable salió 1% más caro (diferencia no significativa respecto a cero); DeepSeek fue un 17% más caro de media.
Incluso entre las 36 tareas de DeepSeek donde los 10 intentos pasaron, RTK mantuvo un coste un 18% superior.

El detalle que mejor ilustra el problema: el supuesto ahorro de Fable dependió prácticamente de una sola tarea (winning-avg-corewars). Sin ella, el resto mostró ahorros por debajo del 1%.

Por qué los tokens ahorrados no se traducen en dinero ahorrado

Quesma identifica tres mecanismos por los que RTK puede ser contraproducente:

1. El agente compensa con más turnos. En DeepSeek, cada turno medio consumió un 7% menos de input con RTK, pero hubo un 18% más de turnos en total. El resultado neto fue un gasto mayor. En 58 tareas RTK necesitó más turnos, y 44 de ellas costaron más.

2. El contexto cacheado reduce el peso real del output. En flujos agentivos, el output de terminal se relee como cache hit: para Fable cuesta 1/10 del input regular y para DeepSeek 1/30. Recortar lo que ya está cacheado apenas mueve la factura.

3. Errores en cascada. En un caso con DeepSeek, el agente entró en un bucle: RTK reescribió un find con un flag no soportado, falló, el agente reintentó, RTK volvió a reescribirlo. Acumuló 339 errores consecutivos antes de agotar el timeout. Pasó la tarea, pero costó 9× más que el intento base equivalente.

Quesma también detectó una rareza contable: en la tarea train-fasttext, RTK acreditó 120,5 millones de tokens ahorrados en dos llamadas a head -1, comparando esa salida parcial contra el archivo completo. Esas dos llamadas supusieron el 69% del contador de ahorro del experimento — un artefacto de medición, no un ahorro real.

Patrón consistente con otros benchmarks independientes

El resultado no es un caso aislado. JetBrains ejecutó SkillsBench con otro optimizador de tokens, caveman (casi 70.000 estrellas en GitHub), sobre 86 tareas reales con Claude Sonnet 5. Su benchmark, reportado por TechTimes, encontró que las savings del 65% del README se reducían a un techo del 8,5-9% en tareas agentivas, donde el código y los tool outputs dominan el stream de tokens. El veredicto del ingeniero Denis Shiryaev: «Safe, honest about style, oversold on savings».

La conclusión es coherente: los modelos frontier actuales ya usan técnicas como head -n o tail -n por sí solos para acotar la salida. RTK probablemente fue más útil con modelos anteriores; hoy es una optimización de nicho, no una fuente de ahorro generalizada.

Qué significa esto para tu startup

Si estás pagando facturas crecientes de Claude Code o Codex, el problema rara vez está en el output de la terminal. Está en:

Elección de modelo. Anthropic lanzó Claude Sonnet 5 en junio de 2026 a 3 dólares por millón de input y 15 por millón de output (post-31 de agosto), y Fable 5.1 en septiembre con cache reads a 0,25 dólares por millón, lo que según The Decoder recorta hasta un 45% los flujos agentivos largos. Elige el modelo adecuado por nivel de esfuerzo en lugar de pagar el flagship para todo.
Diseño del agente. Limita tools, establece system prompts concisos y separa responsabilidades entre subagentes. Cada tool call innecesario pesa más que cualquier filtro de output.
Mide coste por tarea resuelta, no por tokens ahorrados. Un RTK gain alto puede coincidir con un intento más caro, como demuestra Quesma.

Acciones concretas para tu próxima semana

Audita tus últimas 10 sesiones de Claude Code y mide qué porcentaje de tokens vino de output de terminal. Si está por debajo del 15%, RTK probablemente no te compensará.
Cambia el modelo por defecto a Sonnet 5 o Fable 5.1 low effort para tareas rutinarias (tests, refactors, documentación) y reserva Opus solo para problemas donde realmente lo necesites.
Mide por tarea, no por ejecución. Si una misma tarea termina pasando en 3 turnos sin RTK y en 5 turnos con RTK, la «optimización» está costando dinero.