AIDive

4 ahorradores de tokens en Claude Code (uno sale más caro)

Por AIDive · Publicado el

Agentes de programación

JetBrains dice que no, mi máquina dice 11,6 millones

En julio de 2026, JetBrains gastó unos 320 $ de crédito de API — 425 pruebas facturadas — para evaluar rtk, un proxy de shell que decenas de miles de desarrolladores instalan para ahorrar tokens en Claude Code. El veredicto: las sesiones salieron un 7,6 % más caras por tarea. Dos semanas antes, el mismo equipo había medido caveman, la skill que se anuncia como un recorte del 65 % de tokens, y obtuvo un 8,5 %. En mi propia máquina, rtk gain reporta 11,6 millones de tokens ahorrados en 25 599 comandos.

Ambas series de cifras son reales. No miden lo mismo: una es el coste por tarea completada, la otra son bytes de salida de bash.

Cifra Qué mide Fuente
+7,6 % por tarea (p=0,004) Coste de extremo a extremo de una tarea con rtk instalado JetBrains, 425 pruebas, ~320 $
8,5 % de los tokens de salida Ahorro medido de caveman en trabajo agéntico JetBrains, 82 tareas emparejadas
65 % Ahorro anunciado por caveman README de caveman
11,6 M ahorrados (41,6 %) Bytes de salida de bash comprimidos por rtk rtk gain, 25 599 comandos

Este es el stack, cuatro herramientas: graphify, rtk, Superpowers y caveman, 575 612 estrellas de GitHub entre las cuatro al 2026-09-02. Cada una toca una porción distinta de la factura.

Herramienta Estrellas (2026-09-02) Lenguaje Licencia
Superpowers 280 792 Skills en Markdown MIT
graphify 113 946 Python Apache-2.0
caveman 102 548 Go MIT (skill)
rtk 78 326 Rust Apache-2.0

Adónde van los tokens en realidad

Una factura de Claude Code tiene dos caras. Los tokens de entrada son todo lo que el modelo lee: la salida de cada comando de shell, tu prompt, el prompt del sistema y todo el historial de conversación reproducido en cada llamada. Los tokens de salida son todo lo que el modelo escribe.

La propia documentación de rtk dibuja exactamente ese árbol y añade una frase que su post de lanzamiento no tenía: «Un comando que muestra un 90 % menos de bytes de salida no hace que tu sesión sea un 90 % más barata».

JetBrains puso números al lado de la lectura reproduciendo 83 sesiones de referencia, 1,9 millones de caracteres de salida de herramientas.

Porción de lo que el modelo lee Caracteres Cuota
Salida de shell que rtk puede comprimir 373 339 19,7 %
Salida de shell para la que rtk no tiene regla 879 326 46,3 %
Herramientas de lectura y búsqueda que se saltan rtk 646 613 34,0 %

Solo una quinta parte de lo que el modelo lee es comprimible por un proxy de shell: las herramientas integradas Read, Grep y Glob de Claude Code nunca pasan por el hook de Bash.

De ahí sale el mapa de las cuatro herramientas: graphify reduce lo que el agente lee, rtk reduce lo que el shell devuelve, Superpowers reduce el historial que carga cada tarea y elige qué modelo lo carga, y caveman reduce lo que el agente dice. La lectura es la mitad más grande de la factura, así que el ranking empieza ahí.

graphify: recorrer nodos, no líneas

graphify es una skill que convierte una base de código — con sus docs, esquemas SQL, configuraciones y PDF — en un grafo de conocimiento consultable. Escribes /graphify . en Claude Code, Cursor, Codex o Gemini CLI, y el proyecto se mapea una vez para que el agente consulte el grafo en lugar de greppear archivos.

El código se parsea con AST de tree-sitter en unos 40 lenguajes: determinista, sin llamada al LLM, nada sale de la máquina. La construcción cuesta cero créditos de LLM. Produce tres archivos: graph.html para explorar con clics, GRAPH_REPORT.md y graph.json — el grafo en sí, consultable sin releer tus archivos. Cada nodo es un concepto (un archivo, una función, una clase), y cada arista lleva la etiqueta EXTRACTED cuando era explícita en el código o INFERRED cuando graphify la resolvió. Los nodos se agrupan en subsistemas con el algoritmo de Leiden.

El benchmark integrado, ejecutado sobre uno de nuestros proyectos:

Métrica Valor
Nodos 34 031
Aristas 56 865
Comunidades detectadas 967
Procedencia de las aristas 76 % EXTRACTED · 24 % INFERRED
Lectura ingenua del corpus completo 1 701 550 palabras ≈ 2 268 733 tokens
Consulta media al grafo ~24 702 tokens
Reducción 91,8× menos tokens por consulta

Por pregunta la horquilla es amplia: 679,1× en «what is the main entry point», 34,0× en «what connects the data layer to the api».

Dos límites. La comparación es contra leerlo todo, y una sesión guiada por grep nunca costó eso, así que la ganancia real es menor. Y el grafo se queda obsoleto — refréscalo con graphify update <path>, --watch o los hooks de git — mientras que la pasada semántica sobre docs, PDF e imágenes sí llama a un modelo y sí gasta tokens.

Instalación: uv tool install graphifyy (el nombre del paquete lleva doble y), luego graphify install.

rtk: el proxy de shell a juicio

rtk es un proxy de CLI entre Claude Code y tu shell. Comandos corrientes como ls, cat o git status devuelven ruido que el agente debe leer como tokens de entrada: permisos de archivos, barras de progreso, cien líneas de tests que pasan. rtk ejecuta el mismo comando y devuelve una versión compacta: un único binario en Rust, más de 100 comandos soportados, menos de 10 ms de sobrecarga. Un hook PreToolUse reescribe cada llamada de Bash elegible (git statusrtk git status) antes de ejecutarla, así el agente nunca tiene que recordarlo.

El post de lanzamiento del autor afirmaba 10,2 M de tokens ahorrados en dos semanas, un 89,2 %, con ejemplos como cargo test pasando de 155 líneas a 3. Nuestro propio panel tras 25 599 comandos:

Comando Llamadas Tokens ahorrados Tasa
rtk find 354 2,2 M 46,6 %
rtk read 3 504 2,2 M 10,4 %
rtk grep 2 760 1,9 M 47,7 %
rtk ps aux 24 1,1 M 98,0 %
rtk diff 39 541,1 K 92,2 %
Total 25 599 11,6 M 41,6 %

Llega el juicio. JetBrains instaló rtk tal como se distribuye y ejecutó 86 tareas dos veces con claude-sonnet-5.

Hallazgo de JetBrains Valor
Comandos de shell que rtk puede reescribir 349 de 1 056 (1 de cada 3)
Techo del ahorro total ~3 % de la factura
Coste por tarea, esfuerzo de razonamiento bajo +7,6 % (p=0,004)
Turnos por tarea +13,8 % (p=0,03)
Coste por tarea, esfuerzo alto ±0 %
Calidad de las tareas Sin cambios

El README de rtk ya lo dice sin rodeos: hasta un 90 % de la salida de bash, «que no es lo mismo que recortar tu factura un 90 %», y sus propios recuentos se estiman como bytes / 4.

Veredicto: es gratis, la compresión es real y, en palabras de JetBrains, «a menudo elegante». Consérvalo para sesiones cargadas de bash; no esperes que mueva la factura.

Superpowers: encuadrar primero, luego tareas demasiado pequeñas para fallar

Superpowers es el plugin de Jesse Vincent para Claude Code — 280 792 estrellas, catorce skills, un solo comando de instalación (/plugin install superpowers@claude-plugins-official). Ahorra tokens sin comprimir nada.

Todo empieza por la skill de brainstorming, que abre con una barrera dura: nada de código, nada de scaffolding, ninguna skill de implementación hasta que se aprueba una intención explícita. Cuando la skill se carga, el agente se convierte en un compañero de brainstorming y, en la práctica, partes del proyecto se replantean antes de construir nada. Es la etapa que más importa, porque los tokens más caros son los que se gastan construyendo lo equivocado.

La skill clasifica el trabajo como spike, cambio acotado o cambio arquitectónico, y la regla está escrita en el archivo: «Ante la duda entre dos caminos, toma el más pesado». Incluso nombra el modo de fallo, con una sección anti-patrón titulada «Too Simple To Need Approval». El camino arquitectónico produce una spec que validas y luego un plan de implementación.

El plan es de donde viene la fiabilidad. La skill writing-plans corta el trabajo en pasos de una sola acción, de 2 a 5 minutos: escribir el test que falla, ejecutarlo para confirmar que falla, escribir el código mínimo que lo hace pasar, volver a ejecutar los tests, commitear. Los planes se escriben asumiendo que el ingeniero no tiene contexto. Una tarea así de pequeña cabe en una ventana de contexto fresca con margen de sobra, así que el agente nunca llega al final de una tarea con la ventana saturada — y la saturación es de donde sale el código alucinado.

El límite es la ceremonia. El archivo dice que escala con la tarea, pero la barrera se dispara igual en un arreglo de una línea, y eso también son tokens.

Superpowers: una tarea, un subagente, un modelo a medida

Luego el plan se ejecuta y cambia la aritmética de tokens. Una tarea, un subagente. Cada subagente arranca con un contexto fresco que solo contiene su tarea, nunca el historial de la sesión, así la ventana del orquestador se mantiene pequeña y la del subagente limpia. Tras cada tarea el orquestador revisa el resultado: OK, siguiente tarea; no OK, el arreglo vuelve a un subagente. Cinco rondas máximo por tarea — las rondas 1 a 3 retoman al implementador original, la ronda 4 pasa el trabajo a un implementador nuevo con un modelo más capaz, y en la ronda 5 decide el propio orquestador.

La regla que paga todo lo demás es la selección de modelo: «Usa el modelo menos potente que pueda con cada rol para ahorrar coste». El orquestador puntúa la dificultad de cada tarea y elige el modelo acorde.

Tipo de tarea Nivel de modelo
Mecánica, bien especificada; el plan ya trae el código Modelo más barato / pequeño
Coordinación multiarchivo, depuración Modelo estándar
Arquitectura, revisión final de la rama Modelo más capaz
Modelo omitido Hereda el modelo de la sesión

Un matiz del mismo archivo: «El número de turnos gana al precio del token». Un modelo barato que necesita tres turnos no es barato. En la práctica, esto es lo que hace usables Opus y Fable en un plan Pro de 20 $: el modelo caro toca un puñado de tareas en vez de toda la sesión.

La última ganancia es la documentación. Cada spec y cada plan es un archivo markdown guardado en docs/superpowers/specs/ y docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md, commiteado al terminar el trabajo. En el propio pipeline de este canal, la migración a nuestro motor de vídeo actual es una spec más un plan de catorce tareas que todavía puedes abrir, mencionar en una sesión nueva y ampliar. Nada de lo que hicieron los agentes queda sin rastro.

caveman y el estilo Concise: decir menos

La última porción es lo que el agente dice. Los agentes narran — «claro», «encantado de ayudar», «el problema que experimentas probablemente se deba a» — y eso son tokens de salida para nada.

caveman es una skill de Julius Brussee, 102 548 estrellas, que hace que el agente hable como un cavernícola: eliminar artículos, relleno, cortesías y matizaciones, y seguir el patrón [cosa] [acción] [razón]. [siguiente paso]. El código, los comandos, las rutas de archivos y los mensajes de error exactos nunca se cavernizan; solo la prosa que los rodea. Trae tres niveles (/caveman lite|full|ultra) y un hook SessionStart que lo activa al arrancar.

Su propia tabla, diez prompts por la API de Claude, promedia 1 214 tokens de salida sin la skill y 294 con ella — un 65 %, con un mejor caso del 87 % y un peor caso del 22 %.

El README aporta el baño de realidad por sí mismo: la skill solo acorta la salida, los tokens de entrada y de razonamiento no cambian, y sus propias reglas cuestan entre 1 y 1,5 k tokens de entrada en cada turno. JetBrains la midió en 82 tareas agénticas emparejadas, por unos 106 $ de crédito.

caveman Anunciado Medido (JetBrains)
Ahorro de tokens de salida 65 % 8,5 % (592 k → 542 k)
Impacto en calidad Sin degradación detectable (test de signos p=0,82)

La brecha es estructural: la salida de un agente es sobre todo código y llamadas a herramientas, que caveman deja intactos con buen criterio. La recomendación de JetBrains: «úsala si te gusta. Es divertida y no te cuesta nada medible en calidad».

Desde Claude Code v2.1.237 existe un equivalente integrado, el estilo de salida Concise: Claude «empieza por el resultado, se salta el preámbulo y la narración, y mantiene respuestas cortas por defecto». Se elige en /config → Output style; se guarda en .claude/settings.local.json y surte efecto tras /clear o en una sesión nueva. Un límite que comparten ambos: los estilos de salida se aplican solo a la conversación principal — un subagente ejecuta su propio prompt de sistema.

Veredicto: qué mueve la factura, qué mueve los márgenes

Ranking según lo que cada herramienta mueve de verdad, con el coste que carga cada una.

Puesto Herramienta Qué mueve Efecto medido El coste
1 Superpowers El historial por tarea + qué modelo lo lee El modelo caro en un puñado de tareas en vez de toda la sesión Una barrera en cada tarea, incluso arreglos de una línea
2 graphify Lo que el agente lee 91,8× menos tokens por consulta que una lectura ingenua del corpus (nuestro proyecto) El grafo se queda obsoleto; la pasada semántica gasta tokens
3 rtk Bytes de salida de bash Techo ~3 % de la factura; +7,6 % por tarea a esfuerzo bajo en la prueba de JetBrains Solo 1 de cada 3 comandos de shell tiene regla
4 caveman / Concise La prosa que escribe el agente 8,5 % de los tokens de salida, sin pérdida de calidad ~1 a 1,5 k tokens de entrada en cada turno

Superpowers gana, y no por compresión alguna: un contexto fresco por tarea y el modelo más barato que sirva cambian qué se lee y quién lo lee. graphify es segunda porque leer menos es la mitad más grande de la factura. rtk es real, gratis e inofensivo, pero dos tercios de los comandos de shell y todas las lecturas de archivos lo esquivan. caveman, o el estilo Concise que Claude Code ya incluye, recorta la porción más pequeña.

Las cuatro son gratis de instalar — graphify y rtk bajo Apache-2.0, Superpowers bajo MIT, la skill caveman bajo MIT. Más de 570 000 estrellas dicen que la gente quiere un milagro. La versión honesta es un ranking.

Fuentes

Preguntas frecuentes

¿Cuál es la mejor forma de ahorrar tokens en Claude Code?
Cambiar qué lee el agente y qué modelo lo lee, en lugar de comprimir texto. El plugin Superpowers da a cada tarea un contexto de subagente fresco que contiene solo esa tarea, y asigna el modelo menos potente capaz de resolverla. Eso mueve mucha más factura que cualquier compresor de salida.
¿rtk reduce de verdad el coste de Claude Code?
Apenas. Su compresión de la salida de shell es real, pero JetBrains halló que solo 1 de cada 3 comandos de shell tiene regla y que solo una quinta parte de lo que lee el modelo es comprimible, lo que limita el ahorro a un 3 % de la factura. En su A/B de 86 tareas, rtk salió un 7,6 % más caro por tarea con esfuerzo de razonamiento bajo e idéntico con esfuerzo alto, sin cambios de calidad.
¿Por qué rtk reporta millones de tokens ahorrados si no baja la factura?
rtk cuenta los bytes de salida de bash que eliminó, estimados como bytes/4, no dinero. Nuestro panel muestra 11,6 M de tokens ahorrados (41,6 %) en 25 599 comandos. Su propia documentación lo dice directamente: un comando que muestra un 90 % menos de bytes no hace tu sesión un 90 % más barata.
¿Qué es graphify y ahorra tokens?
graphify es una skill /graphify que parsea localmente una base de código con tree-sitter para convertirla en un grafo de conocimiento consultable, sin llamada al LLM y con cero créditos para la construcción. El agente recorre después nodos lógicos en vez de greppear archivos. En nuestro proyecto el benchmark integrado midió 91,8× menos tokens por consulta que leer el corpus entero, aunque esa referencia es una lectura ingenua, no una sesión guiada por grep.
¿Merece la pena instalar la skill caveman?
Solo si te divierte. Anuncia un recorte del 65 % pero JetBrains midió un 8,5 % de los tokens de salida en 82 tareas emparejadas, sin degradación detectable de la calidad, porque el código y las llamadas a herramientas quedan correctamente intactos. Además sus propias reglas añaden entre 1 y 1,5 k tokens de entrada en cada turno.
¿Qué es el estilo de salida Concise en Claude Code?
Un estilo de salida integrado, disponible desde Claude Code v2.1.237, que hace que Claude empiece por el resultado, se salte el preámbulo y la narración, y mantenga respuestas cortas. Se elige en /config, se guarda en .claude/settings.local.json y se aplica solo a la conversación principal: los subagentes conservan su propio prompt de sistema.
¿Cómo hace Superpowers usables Opus o Fable en un plan de 20 $?
Su skill subagent-driven-development indica al orquestador que use el modelo menos potente capaz de cubrir cada rol: el nivel más barato para tareas mecánicas bien especificadas, un modelo estándar para trabajo multiarchivo y depuración, y el más capaz solo para arquitectura y la revisión final. Así el modelo caro toca un puñado de tareas en vez de la sesión entera.

Vídeos relacionados