Ahorrar tokens: la caché sí, el atajo no

TokenEconomizer aprende de las sesiones que ya has hecho

Un agente de programación no cobra por encargo, sino por cada paso: leer un fichero, lanzar los tests o corregir un error es otra petición al modelo. Y quien trabaja a diario en el mismo repositorio paga una y otra vez por lo mismo, según los autores de TokenEconomizer: los mismos datos redescubiertos, las mismas herramientas sin usar enviadas en cada petición y los mismos bucles de fallos.

TokenEconomizer quiere recortar ese gasto «sin cambiar el propio agente»: aprende de las sesiones ya hechas en un repositorio y quita despilfarro en las siguientes. Lo firman once investigadores de Microsoft Research, la división de investigación de Microsoft; de Microsoft Security, su área de seguridad, y de la Universidad de California en Berkeley, la universidad pública californiana.

Publicaron el artículo el 15 de octubre y la versión 0.1.0 del código el 26, con licencia Apache 2.0. Funciona con Claude Code, Codex, GitHub Copilot CLI y Pi, y de forma experimental con opencode.

Se instala como complemento y no pide clave propia

No pide clave de API propia ni maneja credenciales: sus llamadas a un modelo pasan por tu propio agente, y lo que aprende se queda en tu máquina, en `~/.tokeneconomizer`. Si algo falla, la sesión sigue como si no estuviera, según su documentación. Requiere Python 3.10 o posterior y declara soporte para Claude Code de la 2.1.300 a la 2.1.310; con la 2.1.316 de esta prueba funcionó a la primera.

Cada turno vuelve a pagar todo lo anterior

La documentación de TokenEconomizer lo resume así: «cada turno vuelve a pagar las instrucciones del agente, cada herramienta cargada y la conversación hasta ese momento».

En la prueba, la primera petición de cada sesión ya llevaba unos 20.900 tokens antes de que el agente hiciera nada: las instrucciones de Claude Code, las del repositorio y la descripción de 24 herramientas. Cada paso posterior reenvía todo eso, más lo leído y escrito hasta entonces. Casi todo es relectura, y la relectura tiene su propia tarifa.

La caché cobra al 5 % lo que se repite

En la prueba, leer de la caché costaba 0,10 dólares por millón de tokens, el 5 % de los 2 dólares de la entrada normal; escribir en ella, 2,50 dólares, 1,25 veces la entrada, y la salida, 10 dólares.

La tabla lo muestra con las diez tareas de la ronda 1 sin TokenEconomizer: casi 85 de cada 100 tokens se leyeron de la caché, pero esa relectura fue solo el 14,5 % de la factura. Lo que más pesó en dólares fue escribir la caché, seguido de la salida.

Esto cambia dónde está el ahorro: quitar texto del principio del prompt rebaja tokens que se cobran a una vigésima parte, y cualquier cambio ahí obliga a escribir la caché de nuevo, que es lo más caro.

Tres recortes: hechos, herramientas y bucles

El primero, micro-skills, recuerda cómo funciona el repositorio: que allí los tests se lanzan con `python -m pytest`, por ejemplo. Aprende esos hechos de fallos repetidos y de un modelo que repasa las sesiones recientes cada tres, y solo los inyecta cuando tres sesiones los han confirmado. Viene apagado de fábrica porque añade llamadas a un modelo.

El segundo, la poda de herramientas (tool pruning), deja fuera de las sesiones siguientes la herramienta que pasa 10 peticiones (prompts) sin usarse, repartidas en al menos 2 sesiones, o 5 sesiones enteras. En Claude Code lo escribe en `.claude/settings.local.json`, y `toolprune restore` lo deshace. Solo aplica la lista tras 60 minutos sin actividad en el repositorio, o un día después como mucho, para no obligar a reescribir la caché de una conversación que se retoma.

El tercero, el vigilante de bucles (loop guard), actúa si los mismos fallos se repiten: un segundo modelo hace de juez y, con una confianza de al menos 0,7, añade una nota para que el agente cambie de enfoque. Nunca detiene un turno por su cuenta.

Lo que miden sus autores: entre un 18,4 % y un 30,9 % menos

Los autores probaron cinco combinaciones de agente y modelo en 277 tareas de SWE-Bench de seis repositorios, empezando sin nada aprendido. Según sus datos, el coste medio bajó entre un 18,4 % y un 30,9 %, fue menor en las 30 celdas de repositorio y combinación, y el acierto a la primera subió en cuatro de las cinco combinaciones. Sus costes incluyen las llamadas del propio TokenEconomizer.

Son sus propias cifras, en un artículo de arXiv sin revisión por pares, con el código para repetirlas, y medidas en tareas más largas que las de la prueba de abajo.

La prueba: diez tareas reales con Claude Code

Se le dieron diez encargos pequeños a Claude Code 2.1.316 con Sonnet 5.5 sobre una copia del repositorio de twinforce.es, una web en Astro y TypeScript que se prueba con vitest: contar artículos, validar fechas con sus tests, arreglar un fallo sembrado, un botón para compartir en Telegram o una clave de traducción en seis idiomas. Cada tarea arrancó en una sesión nueva desde la copia limpia, y el resultado se comprobó después, sin que el modelo lo viera, con tests ocultos, mutaciones y un cálculo independiente.

Cuatro configuraciones trabajaron en paralelo, tarea a tarea: Claude Code sin complemento, como referencia; TokenEconomizer recién instalado, con poda y vigilante encendidos y micro-skills apagado; la poda inmediata, sin la espera de una hora (`toolprune_quiet_minutes=0`), y esa misma con micro-skills. Las llamadas propias del complemento fueron, con el ajuste por defecto, a Haiku 5.5.

Cada configuración hizo las diez tareas tres veces: la ronda 1 es la práctica, la 2 mide cuánto varía el resultado por sí solo y la 3 queda fuera por un efecto de la caché. En total, 120 sesiones y unos 5,09 dólares a precio de lista.

El resultado: el ahorro se confunde con el ruido

Las cuatro configuraciones resolvieron bien todas las tareas y costaron casi lo mismo: con los ajustes por defecto, algo más; con poda, algo menos. La ronda 2, con diez sesiones de experiencia, deja el mismo dibujo.

El problema es el tamaño. Repetir la sesión sin complemento ya mueve el total un 1,3 %, y cada tarea, un 4 % de media y hasta un 9,6 %. Las diferencias del complemento quedan algo por encima del ruido del total y dentro del de cada tarea: son del mismo orden, y con una sola repetición de la referencia no se pueden separar de él. El 18,4-30,9 % que declaran sus autores en SWE-Bench no se reproduce aquí, algo esperable con tareas cortas y bien especificadas, por los motivos que siguen.

La poda recorta el prompt un 23 % y la factura un 2 %

Con los ajustes por defecto, la poda no quitó nada en 30 sesiones. Tras la ronda 1 ya tenía una lista de 12 herramientas, pero quedó pendiente: espera 60 minutos sin actividad, y entre sesión y sesión nunca pasó una hora. Es el diseño, pero quien lo pruebe una tarde seguida no verá la poda.

La poda inmediata quitó 12 herramientas desde la sexta sesión, y desde la séptima con micro-skills, más una en la ronda 2: las de programar tareas, hablar con otros agentes, enviar avisos o abrir copias de trabajo aparte. La primera petición adelgazó un 23 %, pero el coste apenas se movió.

Las definiciones de herramientas van en la parte del prompt que se lee de la caché al 5 % de la tarifa normal: recortarlas rebaja tokens ya baratos. Además, la primera sesión tras la poda reescribe la caché, y TokenEconomizer añade unos 320 tokens fijos por petición con la descripción de sus comandos.

Ni bucles que cortar ni hechos que ahorrar

El vigilante de bucles no llegó a probarse: en las 90 sesiones con TokenEconomizer, cero llamadas al juez y cero redirecciones. Ninguna tarea se atascó; todas se resolvieron en entre 2 y 7 turnos.

Micro-skills aprendió seis hechos ciertos, como dónde viven los tests y cómo se ejecutan, y los inyectó en cada sesión. No ahorró más que la poda sola: los encargos ya decían qué hacer y dónde.

Con los ajustes por defecto y con la poda inmediata, el complemento no hizo llamadas propias en las sesiones; aparte queda `refresh-catalog`, que se lanza una vez al instalar y costó entre 0,01 y 0,02 dólares por configuración. Con micro-skills gastó unos 0,025 dólares, cerca del 1,9 % del coste, según una estimación con el precio de Haiku 5.5. Su informe, `te status`, da un 25,3 % porque suma tokens de Haiku y de Sonnet como si costaran lo mismo.

Mide tu gasto antes de recortar

La lección práctica no es el complemento, sino la medida. Claude Code da el coste de cada sesión en modo no interactivo con `claude -p "tu encargo" --output-format json`: la respuesta trae `total_cost_usd`, los turnos en `num_turns` y los tokens en `usage`. Con `jq '{coste: .total_cost_usd, turnos: .num_turns, usage: .usage}'` se ve de un vistazo. Es el precio de lista, no una factura, pero sirve para comparar.

Lo que más movió ese coste fue la caché. La ronda 3 empezó justo al acabar la 2, y cada tarea repitió unos 2,5 minutos después un prompt idéntico: la caché de cinco minutos lo sirvió como relectura y las cuatro configuraciones costaron entre un 23 % y un 43 % menos.

De ahí, tres reglas: todas las configuraciones a la misma hora; más de cinco minutos entre dos repeticiones del mismo encargo, y la referencia repetida al menos dos veces. Si la diferencia que buscas es menor que ese ruido, no la has medido.

Pruébalo en tu repositorio sin tocar tu configuración

Trabaja sobre una copia del repositorio y con una carpeta de configuración aparte: Claude Code la toma de `CLAUDE_CONFIG_DIR`, y TokenEconomizer guarda lo aprendido en `TOKENECONOMIZER_HOME`.

Paso 1: con las dos variables apuntando a carpetas nuevas, `git clone https://github.com/microsoft/TokenEconomizer.git`, `claude plugin marketplace add "$PWD/TokenEconomizer"` y `claude plugin install tokeneconomizer@tokeneconomizer`. Sin sesión iniciada en esa configuración, Claude Code pedirá `/login` o usará tu `ANTHROPIC_API_KEY`.

Paso 2: en la copia, ejecuta `/tokeneconomizer:toolprune refresh-catalog` una vez, y otra tras cada actualización de Claude Code. Para pruebas seguidas, `"$TOKENECONOMIZER_HOME/bin/te" --host claude config set toolprune_quiet_minutes=0` quita la espera de una hora.

Paso 3: cada encargo, en sesión nueva tras `git reset --hard` y `git clean`, con `claude -p "tu encargo" --model sonnet --output-format json > tarea-01.json`. Decide antes qué cuenta como bien resuelto; dar permisos totales al agente solo es razonable en una copia desechable.

Paso 4: repite con otra configuración sin el complemento, al menos dos veces, para conocer tu ruido. `TE_DISABLE=1` no sirve de referencia: deja en el prompt los cerca de 320 tokens del complemento.

Paso 5: compara `total_cost_usd` tarea a tarea y mira qué hizo el complemento, sin gastar un turno, con `"$TOKENECONOMIZER_HOME/bin/te" --host claude status`. `toolprune restore` devuelve lo podado, y cómo desinstalarlo está en `plugin/README.md` de su repositorio.

Lo que esta prueba no dice

Diez tareas no son SWE-Bench. En las rondas 1 y 2, cada encargo costó unos 5 céntimos de dólar y duró entre 3 y 7 turnos, con prompts que ya decían el qué y el dónde. Hubo una sola repetición por tarea y ronda, y las configuraciones corrieron en paralelo contra la misma organización de la API, así que su caché pudo cruzarse.

Tampoco dice que TokenEconomizer no sirva en sesiones largas o en repositorios donde el agente se pierde y se atasca, donde sus mecanismos tienen algo que cortar: eso no se ha medido. Dice que en encargos cortos y precisos no hubo ahorro medible, y que la forma de saber cuál es tu caso es medir el tuyo.

La otra palanca para bajar la factura, elegir modelo por su coste por tarea, está en «Mismo precio por token, casi ocho veces más caro» (28-10-2026).