Estalviar tokens: la memòria cau sí, la drecera no

TokenEconomizer aprèn de les sessions que ja has fet

Un agent de programació no cobra per encàrrec, sinó per cada pas: llegir un fitxer, llançar els tests o corregir un error és una altra petició al model. I qui treballa cada dia al mateix repositori paga una vegada i una altra pel mateix, segons els autors de TokenEconomizer: les mateixes dades redescobertes, les mateixes eines que no es fan servir enviades a cada petició i els mateixos bucles d'errors.

TokenEconomizer vol retallar aquesta despesa «sense canviar l'agent mateix»: aprèn de les sessions ja fetes en un repositori i elimina malbaratament en les següents. El signen onze investigadors de Microsoft Research, la divisió de recerca de Microsoft; de Microsoft Security, la seva àrea de seguretat, i de la Universitat de Califòrnia a Berkeley, la universitat pública californiana.

Van publicar l'article el 15 d'octubre i la versió 0.1.0 del codi el 26, amb llicència Apache 2.0. Funciona amb Claude Code, Codex, GitHub Copilot CLI i Pi, i de manera experimental amb opencode.

S'instal·la com a complement i no demana clau pròpia

No demana clau d'API pròpia ni gestiona credencials: les seves crides a un model passen pel teu propi agent, i el que aprèn es queda a la teva màquina, a `~/.tokeneconomizer`. Si alguna cosa falla, la sessió continua com si no hi fos, segons la seva documentació. Requereix Python 3.10 o posterior i declara compatibilitat amb Claude Code de la 2.1.300 a la 2.1.310; amb la 2.1.316 d'aquesta prova va funcionar a la primera.

Cada torn torna a pagar tot l'anterior

La documentació de TokenEconomizer ho resumeix així: «cada torn torna a pagar les instruccions de l'agent, cada eina carregada i la conversa fins a aquell moment».

A la prova, la primera petició de cada sessió ja portava uns 20.900 tokens abans que l'agent fes res: les instruccions de Claude Code, les del repositori i la descripció de 24 eines. Cada pas posterior reenvia tot això, més el que s'ha llegit i escrit fins llavors. Gairebé tot és relectura, i la relectura té la seva pròpia tarifa.

La memòria cau cobra al 5 % el que es repeteix

A la prova, llegir de la memòria cau costava 0,10 dòlars per milió de tokens, el 5 % dels 2 dòlars de l'entrada normal; escriure-hi, 2,50 dòlars, 1,25 vegades l'entrada, i la sortida, 10 dòlars.

La taula ho mostra amb les deu tasques de la ronda 1 sense TokenEconomizer: gairebé 85 de cada 100 tokens es van llegir de la memòria cau, però aquesta relectura només va ser el 14,5 % de la factura. El que més va pesar en dòlars va ser escriure a la memòria cau, seguit de la sortida.

Això canvia on és l'estalvi: treure text del començament del prompt abaixa tokens que es cobren a una vintena part del preu, i qualsevol canvi en aquesta part obliga a tornar a escriure la memòria cau, que és el més car.

Tres retallades: fets, eines i bucles

La primera, micro-skills, recorda com funciona el repositori: que allà els tests es llancen amb `python -m pytest`, per exemple. Aprèn aquests fets d'errors repetits i d'un model que repassa les sessions recents cada tres, i només els injecta quan tres sessions els han confirmat. Ve desactivada de fàbrica perquè afegeix crides a un model.

La segona, la poda d'eines (tool pruning), deixa fora de les sessions següents l'eina que passa 10 peticions (prompts) sense fer-se servir, repartides en almenys 2 sessions, o 5 sessions senceres. A Claude Code ho escriu a `.claude/settings.local.json`, i `toolprune restore` ho desfà. Només aplica la llista després de 60 minuts sense activitat al repositori, o un dia després com a màxim, per no obligar a reescriure la memòria cau d'una conversa que es reprèn.

La tercera, el vigilant de bucles (loop guard), actua si es repeteixen els mateixos errors: un segon model fa de jutge i, amb una confiança d'almenys 0,7, afegeix una nota perquè l'agent canviï d'enfocament. Mai no atura un torn pel seu compte.

El que mesuren els autors: entre un 18,4 % i un 30,9 % menys

Els autors van provar cinc combinacions d'agent i model en 277 tasques de SWE-Bench de sis repositoris, començant sense res après. Segons les seves dades, el cost mitjà va baixar entre un 18,4 % i un 30,9 %, va ser més baix a les 30 cel·les de repositori i combinació, i l'encert a la primera va pujar en quatre de les cinc combinacions. Els seus costos inclouen les crides del mateix TokenEconomizer.

Són les seves pròpies xifres, en un article d'arXiv sense revisió per parells, amb el codi per repetir-les, i mesurades en tasques més llargues que les de la prova que ve a continuació.

La prova: deu tasques reals amb Claude Code

Es van donar deu encàrrecs petits a Claude Code 2.1.316 amb Sonnet 5.5 sobre una còpia del repositori de twinforce.es, una web en Astro i TypeScript que es prova amb vitest: comptar articles, validar dates amb els seus tests, arreglar un error sembrat, un botó per compartir a Telegram o una clau de traducció en sis idiomes. Cada tasca va arrencar en una sessió nova des de la còpia neta, i el resultat es va comprovar després, sense que el model ho veiés, amb tests ocults, mutacions i un càlcul independent.

Quatre configuracions van treballar en paral·lel, tasca a tasca: Claude Code sense complement, com a referència; TokenEconomizer acabat d'instal·lar, amb la poda i el vigilant activats i micro-skills desactivat; la poda immediata, sense l'espera d'una hora (`toolprune_quiet_minutes=0`), i aquesta mateixa amb micro-skills. Les crides pròpies del complement van anar, amb el valor per defecte, a Haiku 5.5.

Cada configuració va fer les deu tasques tres vegades: la ronda 1 és la pràctica, la 2 mesura quant varia el resultat per si sol i la 3 queda fora per un efecte de la memòria cau. En total, 120 sessions i uns 5,09 dòlars a preu de llista.

El resultat: l'estalvi es confon amb el soroll

Les quatre configuracions van resoldre bé totes les tasques i van costar gairebé el mateix: amb els valors per defecte, una mica més; amb poda, una mica menys. La ronda 2, amb deu sessions d'experiència, dibuixa el mateix panorama.

El problema és la mida. Repetir la sessió sense complement ja mou el total un 1,3 %, i cada tasca, un 4 % de mitjana i fins a un 9,6 %. Les diferències del complement queden una mica per sobre del soroll del total i dins del de cada tasca: són del mateix ordre, i amb una sola repetició de la referència no se'n poden separar. El 18,4-30,9 % que declaren els autors a SWE-Bench no es reprodueix aquí, cosa esperable amb tasques curtes i ben especificades, pels motius que s'expliquen a continuació.

La poda retalla el prompt un 23 % i la factura un 2 %

Amb els valors per defecte, la poda no va treure res en 30 sessions. Després de la ronda 1 ja tenia una llista de 12 eines, però va quedar pendent: espera 60 minuts sense activitat, i entre sessió i sessió no va passar mai una hora. És el disseny, però qui la provi durant una tarda seguida no veurà la poda.

La poda immediata va treure 12 eines a partir de la sisena sessió, i a partir de la setena amb micro-skills, més una a la ronda 2: les de programar tasques, parlar amb altres agents, enviar avisos o obrir còpies de treball a part. La primera petició es va aprimar un 23 %, però el cost a penes es va moure.

Les definicions d'eines van a la part del prompt que es llegeix de la memòria cau al 5 % de la tarifa normal: retallar-les abaixa tokens que ja són barats. A més, la primera sessió després de la poda reescriu la memòria cau, i TokenEconomizer afegeix uns 320 tokens fixos per petició amb la descripció de les seves ordres.

Ni bucles per tallar ni fets per estalviar

El vigilant de bucles no es va arribar a provar: en les 90 sessions amb TokenEconomizer, zero crides al jutge i zero redireccions. Cap tasca no es va encallar; totes es van resoldre en entre 2 i 7 torns.

Micro-skills va aprendre sis fets certs, com on són els tests i com s'executen, i els va injectar a cada sessió. No va estalviar més que la poda sola: els encàrrecs ja deien què calia fer i on.

Amb els valors per defecte i amb la poda immediata, el complement no va fer crides pròpies a les sessions; a banda queda `refresh-catalog`, que es llança un cop en instal·lar-lo i va costar entre 0,01 i 0,02 dòlars per configuració. Amb micro-skills va gastar uns 0,025 dòlars, prop de l'1,9 % del cost, segons una estimació amb el preu de Haiku 5.5. El seu informe, `te status`, dona un 25,3 % perquè suma tokens de Haiku i de Sonnet com si costessin el mateix.

Mesura la despesa abans de retallar

La lliçó pràctica no és el complement, sinó la mesura. Claude Code dona el cost de cada sessió en mode no interactiu amb `claude -p "el teu encàrrec" --output-format json`: la resposta porta `total_cost_usd`, els torns a `num_turns` i els tokens a `usage`. Amb `jq '{cost: .total_cost_usd, torns: .num_turns, usage: .usage}'` es veu d'un cop d'ull. És el preu de llista, no una factura, però serveix per comparar.

El que més va moure aquest cost va ser la memòria cau. La ronda 3 va començar just en acabar la 2, i cada tasca va repetir uns 2,5 minuts després un prompt idèntic: la memòria cau de cinc minuts el va servir com a relectura i les quatre configuracions van costar entre un 23 % i un 43 % menys.

D'aquí surten tres regles: totes les configuracions a la mateixa hora; més de cinc minuts entre dues repeticions del mateix encàrrec, i la referència repetida almenys dues vegades. Si la diferència que busques és més petita que aquest soroll, no l'has mesurada.

Prova-ho al teu repositori sense tocar la teva configuració

Treballa sobre una còpia del repositori i amb una carpeta de configuració a part: Claude Code la pren de `CLAUDE_CONFIG_DIR`, i TokenEconomizer guarda el que aprèn a `TOKENECONOMIZER_HOME`.

Pas 1: amb les dues variables apuntant a carpetes noves, `git clone https://github.com/microsoft/TokenEconomizer.git`, `claude plugin marketplace add "$PWD/TokenEconomizer"` i `claude plugin install tokeneconomizer@tokeneconomizer`. Si no hi ha cap sessió iniciada en aquesta configuració, Claude Code demanarà `/login` o farà servir la teva `ANTHROPIC_API_KEY`.

Pas 2: a la còpia, executa `/tokeneconomizer:toolprune refresh-catalog` un cop, i un altre després de cada actualització de Claude Code. Per a proves seguides, `"$TOKENECONOMIZER_HOME/bin/te" --host claude config set toolprune_quiet_minutes=0` treu l'espera d'una hora.

Pas 3: cada encàrrec, en una sessió nova després de `git reset --hard` i `git clean`, amb `claude -p "el teu encàrrec" --model sonnet --output-format json > tasca-01.json`. Decideix abans què compta com a ben resolt; donar permisos totals a l'agent només és raonable en una còpia d'un sol ús.

Pas 4: repeteix amb una altra configuració sense el complement, almenys dues vegades, per conèixer el teu soroll. `TE_DISABLE=1` no serveix de referència: deixa al prompt els aproximadament 320 tokens del complement.

Pas 5: compara `total_cost_usd` tasca a tasca i mira què ha fet el complement, sense gastar cap torn, amb `"$TOKENECONOMIZER_HOME/bin/te" --host claude status`. `toolprune restore` torna el que s'ha podat, i com desinstal·lar-lo s'explica a `plugin/README.md` del seu repositori.

El que aquesta prova no diu

Deu tasques no són SWE-Bench. A les rondes 1 i 2, cada encàrrec va costar uns 5 cèntims de dòlar i va durar entre 3 i 7 torns, amb prompts que ja deien què calia fer i on. Hi va haver una sola repetició per tasca i ronda, i les configuracions van córrer en paral·lel contra la mateixa organització de l'API, de manera que les seves memòries cau es podien haver creuat.

Tampoc no diu que TokenEconomizer no serveixi en sessions llargues o en repositoris on l'agent es perd i s'encalla, on els seus mecanismes tenen alguna cosa per tallar: això no s'ha mesurat. Diu que en encàrrecs curts i precisos no hi va haver cap estalvi mesurable, i que la manera de saber quin és el teu cas és mesurar el teu.

L'altra palanca per abaixar la factura, triar el model pel seu cost per tasca, és a «El mateix preu per token, gairebé vuit vegades més car» (28-10-2026).