Una afirmación ampliamente compartida de que RTK (Rust Token Killer) puede reducir los costos de tokens de codificación por IA hasta en un 60% — alcanzando 313,000 visualizaciones en X — no se sostiene bajo pruebas de rendimiento sistemáticas. Quesma probó RTK 0.45.0 en Terminal-Bench 2.1, una prueba de rendimiento con mucha interacción en la terminal, ejecutando 1,740 intentos en Claude Code con Fable 5.0 de Anthropic y OpenCode con DeepSeek V4 Pro 0813 a través de OpenRouter. Los resultados, publicados el 11 de septiembre de 2026, muestran que comprimir la salida de la terminal rara vez reduce la factura final y puede aumentarla.
Esta captura de pantalla muestra una de las fuentes virales detrás de la afirmación de 313,000 visualizaciones de que RTK reduce drásticamente los costos de codificación por IA, la cual la prueba de rendimiento sistemática de Quesma en Terminal-Bench 2.1 fue diseñada para contrastar con datos de facturación reales.
### Cómo funciona RTK y qué toca realmente
RTK intercepta los comandos de shell (Bash en Claude Code, bash en OpenCode) y devuelve una salida más concisa. Por ejemplo, `ls -la` normalmente muestra el propietario, la fecha y los permisos; RTK conserva solo los permisos, los nombres de los archivos y los tamaños. Sin embargo, RTK solo reescribe los comandos de shell. Ambas plataformas exponen la lectura y búsqueda de archivos como herramientas separadas de Read, Grep y Glob que omiten por completo a RTK. Aproximadamente la mitad de las llamadas de Bash de Claude Code ya limitan su propia salida con `head`, `tail` o `wc`.
El gráfico de la prueba de rendimiento visualiza cómo la reducción de tokens del 89% reportada por RTK se traduce en ahorros de costos insignificantes o negativos en 1,740 intentos con Fable 5.0 y DeepSeek V4 Pro, con Fable mostrando solo una reducción del 5% en el costo total y DeepSeek mostrando un aumento del 5% en el costo.
### Las cifras principales
A través de 85 tareas de Fable y 89 tareas de DeepSeek (cinco ejecuciones cada una, con y sin RTK):
- **Fable 5.0**: El costo total bajó un 5% con RTK ($596 → $546), la tasa de éxito bajó un 1% (84% → 83%). - **DeepSeek V4 Pro**: El costo total subió un 5% ($26 → $31), la tasa de éxito bajó un 2% (71% → 69%).
Cuando el costo se divide por los aciertos exitosos (contabilizando los fallos), Fable fue un 3% más barato con RTK; DeepSeek fue un 7% más caro. Pero una medida a nivel de tarea — promediando el cambio de costo de cada tarea en lugar de agrupar todos los intentos — cuenta una historia diferente: Fable fue un 1% más caro (sin una diferencia clara del cero), mientras que el costo por tarea de DeepSeek subió un **17% en promedio**. Incluso en las 36 tareas de DeepSeek donde los diez intentos fueron exitosos, el aumento persistió en un 18%.
### Una sola tarea impulsó todos los ahorros de Fable
Casi todos los ahorros aparentes de Fable provinieron de una sola tarea, `winning-avg-corewars`. Ambas configuraciones superaron cada intento, pero RTK terminó en aproximadamente la mitad de los turnos. En las 84 tareas restantes, los ahorros fueron inferiores al 1%. DeepSeek mostró lo contrario en esa misma tarea: RTK tomó más turnos y costó más. Eliminar esa tarea dejó los costos de DeepSeek más altos con RTK.
### La métrica `rtk gain` no es una métrica de costo
RTK documenta `rtk gain` como "salida de comando sin filtrar menos la salida filtrada en bytes, dividida por 4" — no es un recuento de tokens facturados. En 445 intentos de DeepSeek con RTK, RTK reportó 349.2 millones de tokens "ahorrados" (una reducción del 89%). Sin embargo, las tareas se volvieron más caras.
La métrica puede atribuir ahorros por una salida que el agente nunca habría visto. En la tarea `train-fasttext`, el modelo ejecutó `head -1 train.txt` dos veces. RTK acreditó 120.5 millones de tokens ahorrados cada vez al comparar esas lecturas limitadas contra el archivo completo — el 69% de los ahorros reportados de la ejecución — a pesar de que los comandos nunca habrían devuelto el archivo completo. `rtk gain` también ignora el costo de los turnos extra que la compresión puede inducir.
### Los errores pueden multiplicar los costos
Un intento de `git-multibranch` de DeepSeek entró en un bucle: el agente ejecutó un comando `find` con una bandera no compatible con `rtk find` 0.45.0. El plugin lo reescribió como `rtk find`, que falló con "Use find directly." Cada reintento fue reescrito nuevamente, produciendo 339 errores consecutivos durante aproximadamente 12 minutos. El intento aún fue exitoso pero costó **unas 9 veces** más que la línea base correspondiente. RTK corrigió esto en la versión 0.46.0, después de las ejecuciones de Quesma.
### La salida de la terminal es una pequeña parte de la factura
Sin RTK, la salida de las herramientas constituyó aproximadamente el 11% de los tokens de entrada de Fable y el 40% de los de DeepSeek. En las ejecuciones con RTK, solo el 31% de las llamadas de terminal de Claude Code y el 51% de las de OpenCode usaron RTK. El resto las omitió a través de herramientas dedicadas o banderas de autolimitación.
Además, la codificación agéntica cachea el contexto después de cada turno. Las lecturas posteriores de la salida de la terminal aparecen mayormente como lecturas de caché — costando 1/10 de los tokens de entrada regulares para Fable, 1/30 para DeepSeek. Las lecturas de caché constituyeron el 94–98% de los tokens de entrada y el 26–30% de la factura total en las ejecuciones con RTK.
Para DeepSeek, RTK redujo los caracteres de la salida de la terminal en un 9%, pero los tokens de prompt **subieron un 9%**. La entrada no cacheada bajó un 1% mientras que la entrada cacheada subió un 9%. La salida del modelo (incluyendo el razonamiento) representó el 56–57% del costo independientemente de RTK.
### Los turnos extra borran los ahorros de compresión
Cuando RTK causó que el agente realizara más turnos, el costo de la tarea usualmente subió con ellos. Los intentos de DeepSeek con RTK tomaron más turnos en 58 tareas; 44 de esas costaron más. Tomaron menos turnos en 28 tareas; 23 costaron menos. El turno promedio de DeepSeek tuvo un 7% menos de entrada con RTK, pero hubo un 18% más de turnos en total. Los turnos más pequeños no sumaron menos entrada total. Un turno extra del agente puede costar más que la compresión ahorrada — el mismo problema de "tokenflation" en otra forma. JetBrains observó el mismo patrón en SkillsBench: RTK añadió turnos con poco esfuerzo y no bajó el costo con esfuerzo alto.
### Por qué la discrepancia entre los ahorros reportados y el costo real
Los modelos de vanguardia ya usan la terminal de manera eficiente. Solo aproximadamente el 7% del contexto de Fable era salida de terminal sin RTK. Los modelos emplean técnicas como `head -n` y `tail -n` por sí mismos. RTK probablemente ayudó más con modelos más antiguos; hoy es una optimización de nicho, no una fuente general de ahorros. Quesma no recomienda RTK como una herramienta genérica de ahorro de costos.
Las trayectorias están disponibles bajo petición para investigaciones de seguimiento. Quesma planea una prueba de rendimiento futura de Headroom, otro filtro de salida de terminal.