Guilgo Blog

Cuando trabajas con Cursor en tareas reales de infraestructura, debugging, operaciones o revisión de cambios, una parte importante del coste y del ruido viene de la salida del shell: logs largos, listados enormes y comandos repetitivos.

RTK no optimiza comandos. Optimiza el contexto que ve el agente.

En este artículo te explico qué es RTK (Rust Token Killer), por qué encaja muy bien con Cursor y cómo adoptarlo con un enfoque seguro, medible y sin romper tu flujo de trabajo.

Proyecto oficial: rtk-ai/rtk

Por qué importa “contexto” y no “comando”

El comando lo ejecuta tu sistema. El contexto lo consume el agente para decidir el siguiente paso. Ahorrar tokens es un efecto secundario; el objetivo es mejorar la calidad de las decisiones del agente, y mejorar la calidad de las decisiones del agente es el objetivo principal: lo importante es reducir ruido de entrada.

Si una salida trae 2000 líneas pero solo 30 tienen señal operativa, el problema no es que el comando esté mal. El problema es que el agente tiene que navegar basura antes de encontrar lo útil. RTK actúa justo ahí: compacta la salida para que el agente vea primero la parte accionable.

El problema: demasiado texto útil mezclado con demasiado ruido

Si usas agentes de código a diario, seguramente te suena:

• Comandos de Kubernetes que devuelven salidas largas cuando solo quieres un estado resumido.
• Logs con mucha repetición que ocupan contexto sin aportar señal.
• Operaciones de Git que se pueden representar de forma más compacta.
• Iteraciones largas en las que el contexto del agente se llena con salida de shell.

El resultado es simple: más tokens, más coste y más fricción cognitiva.

Qué hace RTK

RTK es un CLI proxy que filtra y comprime la salida de comandos comunes antes de que llegue al contexto del agente.

En la práctica aplica cuatro ideas:

1. Filtrado inteligente de ruido.
2. Agrupación de resultados similares.
3. Truncado con criterio para mantener señal y recortar redundancia.
4. Deduplicación de líneas repetidas.

No sustituye tus herramientas: se integra con ellas (git, kubectl, docker, etc.) para que la salida sea más útil y compacta.

Por qué RTK tiene sentido en Cursor

Cursor, igual que otros agentes, usa shell de forma intensiva durante una sesión: inspección, validación, pruebas y troubleshooting.

RTK ayuda especialmente cuando:

• Ejecutas muchas consultas de estado.
• Tu stack genera salida verbosa.
• Trabajas en ciclos rápidos donde cada comando suma tokens al contexto.

Cursor acumula contexto de iteraciones anteriores, por lo que la reducción de salida tiene efecto acumulativo en sesiones largas.

Caso real en homelab: Kubernetes + Wazuh + troubleshooting

En mi flujo real (homelab con Kubernetes, Wazuh-lite, scripts Python e integraciones de Telegram), hay un patrón que se repite en incidencias:

kubectl get pods -A
kubectl describe pod wazuh-manager-xxxxx -n security
kubectl logs wazuh-manager-xxxxx -n security

Sin RTK, este ciclo puede volcar fácilmente 2000+ líneas en una sola iteración de troubleshooting. Ahí hay señal, sí, pero también muchísimo ruido: eventos repetidos, bloques irrelevantes y detalle que no ayuda en el primer diagnóstico.

Con RTK en ese mismo flujo, la salida útil suele quedarse en el rango de 20-50 líneas accionables para la primera decisión (qué pod mirar, qué error priorizar, qué comando lanzar después). El impacto práctico es inmediato: menos iteraciones con el agente para llegar al siguiente paso correcto.

Cómo medirlo de verdad (sin inventar números)

Si quieres credibilidad técnica, no uses cifras “plausibles”: mide tu propio flujo.

Comandos base:

rtk gain
rtk gain --history
rtk gain --daily

Qué mirar durante 3-7 días:

• Tendencia de reducción por día.
• Comandos donde más ahorras.
• Comandos donde no conviene comprimir.

Con eso puedes publicar una métrica real de tu entorno (no de laboratorio) y defenderla con datos.

Métricas del piloto (datos reales, anonimizado)

Para este post se ejecutó un piloto corto en Cursor con datos de producción anonimizados (sin namespaces sensibles, sin hostnames internos, sin IDs/tokens, sin rutas privadas).

Resumen de rtk gain --all --format json al cierre del piloto:

• total_commands: 12
• total_input: 19941 tokens
• total_output: 1244 tokens
• total_saved: 18707 tokens
• avg_savings_pct: 93.81%
• avg_time_ms: 216 ms

La mayoría del ahorro proviene de comandos de listado (kubectl get, git status, etc.), no de comandos de inspección puntual.

Lectura rápida:

• El ahorro agregado superó con margen el umbral objetivo del piloto (>=50%).
• El mayor impacto apareció en comandos de estado/listado.
• En comandos fuera de repo Git o subcomandos no soportados, RTK no aporta compresión (comportamiento esperado).

Nota metodológica: estos números son útiles como referencia de adopción, no como benchmark universal. El resultado final depende de tu mezcla de comandos y del tipo de sesión.

Batería de pruebas (qué se probó y cómo)

Para que el resultado sea reproducible, esta fue la batería usada en el piloto.

1) Línea base sin RTK

Objetivo: medir volumen bruto de salida en comandos habituales.

Comandos de referencia:

kubectl get pods -A | wc -l
kubectl get svc -A | wc -l
kubectl get deployments -A | wc -l
kubectl logs -n <namespace> <pod> | wc -l
ls -la | wc -l

Qué valida:

• Cantidad de líneas que entran al contexto sin compresión.
• Comandos más propensos a ruido en troubleshooting.

2) Prueba funcional RTK (sin hooks)

Objetivo: validar utilidad de salida compacta antes de automatizar.

Comandos ejecutados:

rtk kubectl pods
rtk kubectl services
rtk kubectl logs <pod> -n <namespace>
rtk git status
rtk git diff
rtk git log -n 10
rtk grep "pattern" .
rtk read README.md

Qué valida:

• Si la salida compacta sigue siendo accionable.
• Dónde RTK aporta claramente.
• Dónde conviene mantener salida nativa.

3) Medición de impacto

Objetivo: cuantificar ahorro y revisar comando a comando.

Comandos de medición:

rtk gain
rtk gain --history
rtk gain --all --format json

Qué valida:

• Ahorro total y promedio.
• Comandos con mayor impacto.
• Comandos con ahorro nulo (para ajustar expectativas).

4) Activación controlada de hooks en Cursor

Objetivo: mantener hábitos de uso normales con reescritura automática.

rtk init -g --auto-patch
rtk init -g --agent cursor
rtk init --show

Qué valida:

• Hook instalado y activo.
• Integración operativa sin cambiar rutina diaria.

Criterio de aceptación del piloto

Se considera adopción válida si se cumplen los 3 puntos:

1. Ahorro agregado >= 50%.
2. Sin pérdida crítica de contexto en debugging.
3. Flujo de trabajo igual o más rápido (sin fricción operativa nueva).

En este caso, el piloto cumplió y se pasó a activación.

Adopción recomendada de RTK en Cursor (sin riesgos)

La mejor forma no es activar todo de golpe. Hazlo en dos fases.

Fase 1: piloto controlado (sin hook automático)

Primero valida con comandos explícitos:

rtk kubectl pods
rtk kubectl services
rtk git status
rtk git diff
rtk grep "pattern" .
rtk read README.md

Objetivo de esta fase:

• Comprobar que la salida sigue siendo accionable.
• Detectar comandos donde prefieres ver salida completa.
• Medir el impacto real con rtk gain.

Fase 2: activar hooks para Cursor

Cuando el piloto sea satisfactorio:

rtk init -g --auto-patch
rtk init -g --agent cursor
rtk init --show

Así consigues reescritura automática en comandos shell sin cambiar tus hábitos.

Impacto real de los hooks: no cambias hábitos. Sigues lanzando comandos como siempre, pero el contexto que entra al agente llega más limpio.

Riesgo real: acostumbrarte a la salida filtrada y perder detalle crítico en momentos delicados.

Recomendación práctica: deja siempre fuera de compresión los comandos de diagnóstico crítico (kubectl logs, curl y equivalentes de inspección exacta).

Configuración práctica para producción

No todo conviene comprimir siempre. Hay comandos sensibles para diagnóstico donde prefieres texto completo.

Archivo recomendado:

~/.config/rtk/config.toml

[hooks]
exclude_commands = ["kubectl logs", "curl"]

[tee]
enabled = true
mode = "failures"
max_files = 20

RTK modifica la salida, no el comando. En debugging profundo (errores intermitentes, parsing, edge cases), la salida filtrada puede ocultar condiciones relevantes. Usa salida nativa cuando el diagnóstico no sea evidente.

Por qué esta configuración

• kubectl logs: en incidentes, el detalle completo suele ser crítico.
• curl: útil para inspección exacta de payloads y respuestas.
• tee en fallos: conserva salida sin filtrar cuando realmente hace falta.

Qué tipo de resultados esperar

RTK publica ahorros típicos altos en comandos comunes, según su documentación y benchmarks del proyecto, especialmente en listados, logs, tests y operaciones repetitivas de CLI.

En un entorno real, el porcentaje exacto variará según:

• Tipo de proyecto.
• Estilo de comandos.
• Cantidad de shell por sesión.
• Perfil de debugging.

Riesgos reales al usar RTK (y cómo mitigarlos)

1) “Me falta detalle para depurar”

Mitigación: excluir comandos críticos en exclude_commands.

2) “No quiero perder evidencia cuando falla algo”

Mitigación: activar tee en modo failures.

3) “No sé si compensa en mi caso”

Mitigación: piloto de 3-7 días y decisión basada en rtk gain.

Qué RTK NO arregla

RTK ayuda mucho con ruido de shell, pero no resuelve problemas estructurales de trabajo con agentes:

• Exceso de archivos cargados en Cursor sin criterio.
• .cursorrules gigantes y poco enfocadas.
• Prompts sin scope claro ni objetivo operativo.

Si la estrategia de contexto está mal planteada, RTK mejora la superficie del problema, pero no corrige la raíz.

Dónde encaja RTK en un homelab serio

En un entorno como el mío, RTK encaja en varios puntos de forma muy natural:

• kubectl: reducción de ruido en debugging diario.
• Logs de Wazuh: filtrado previo para análisis inicial más rápido.
• Scripts CLI en Python: salidas más compactas para iterar con agentes.
• Agentes tipo “Cachifo” (mi asistente personal): mejor contexto de entrada y menos dispersión.

Rollback limpio

Si en cualquier momento quieres volver atrás:

rtk init -g --uninstall

También puedes mantener RTK instalado y desactivar solo hooks de agente según tu flujo.

Buenas prácticas para equipos que usan Cursor

• Define una política mínima de exclusiones (logs críticos y comandos de inspección exacta).
• Revisa métricas semanalmente durante el primer mes.
• Documenta una guía breve para el equipo (qué se comprime y qué no).
• Ajusta por contexto: desarrollo diario no es igual que incident response.

Conclusión

RTK no es solo “ahorrar tokens”: es control de calidad sobre el contexto que recibe el agente.

Si usas Cursor con shell intensivo, no usar RTK es asumir ruido innecesario en cada iteración.

Recursos

• Repositorio oficial: https://github.com/rtk-ai/rtk
• Documentación de instalación y uso en el propio repo.