Els models més barats i el parany dels comptadors de tokens
Més tokens per al mateix text, canvis de tarifa i quotes difícils d’interpretar: què hi ha darrere del preu de Haiku 5.5 i GPT-6 Luna.
Els nous models anuncien preus més baixos per milió de tokens. Però la comparació queda incompleta si el mateix text passa a ocupar més tokens. El preu de la unitat baixa mentre la unitat es fa més petita. El recompte creix sense que nosaltres hi afegim contingut.
Amb Haiku 5.5, aquest augment està documentat: aproximadament un 30% més que amb Haiku 4.5 per al mateix text. S’hi afegeixen els salts de tarifa, les categories que no surten al comptador visible i una barra de quota que no explica com es relaciona amb aquell número.
Aquest és el problema de fons. Un preu anunciat baix no basta per entendre el consum. La rebaixa per token hauria d’anar acompanyada de l’augment del recompte per a la mateixa informació.
Haiku: un 25% en una prova, un 30% segons la documentació
El tokenitzador divideix el contingut en les unitats que fa servir el model. Si el canviem, podem tenir exactament la mateixa frase i un recompte més alt. La guia de migració de Haiku 5.5 situa l’augment del text al voltant del 30%, tot i que varia segons el contingut.
Simon Willison en va publicar una comprovació amb un prompt llarg el 7 d’octubre. El resultat era aproximadament 1,25 vegades el recompte de Haiku 4.5: un 25% més. És una observació concreta, no la mitjana de tots els usos.
L’exemple d’imatge d’Anthropic consumeix unes 2,5 vegades els tokens del model anterior. Això vol dir un 150% més, no un 250% més. Haiku 5.5 en conserva més resolució, de manera que també canvia el detall que processa.
Per al text, si fem servir el 30% com a aproximació, 100.000 tokens antics es converteixen en 130.000. Amb un pressupost fix de 100.000 tokens hi cap un 23,1% menys de text: 100/130 dona aproximadament 0,769. És una comparació amb el mateix pressupost, no entre les mides reals de les finestres de context dels dos models.
Quan el cost arriba a 6,5 vegades el pressupost
Haiku 5.5 anuncia una tarifa Standard d’entrada de 0,10 dòlars per milió fins als 100.000 tokens. Quan el prompt supera aquest llindar, cobra 0,50 per milió en tota la petició. El canvi de recompte pot fer-nos entrar en aquesta tarifa més alta. Tarifes i llindar de Haiku.
Fem un exemple hipotètic, només d’entrada, sense memòria cau, sortida ni eines. Si pressupostem amb el recompte de Haiku 4.5 i la tarifa curta de Haiku 5.5, un text de 50.000 tokens costaria 0,005 dòlars. Aplicant-hi un 30% més de tokens, passa a 65.000 i costa 0,0065: un 30% més del que havíem previst.
Amb un text de 80.000 tokens, el pressupost inicial seria de 0,008 dòlars. Però el nou recompte arriba a 104.000 i supera el llindar: l’entrada costa 0,052 dòlars. Són 6,5 vegades l’estimació, un 550% més. Ho comparem amb el pressupost fet amb el recompte antic i la tarifa curta del model nou, no amb la factura del model anterior.
El preu anunciat ens convida a fer una multiplicació senzilla. Però canvien tant les unitats comptades com el preu que s’hi aplica. En el segon exemple, quedar-nos curts en el recompte també ens fa pressupostar amb la tarifa equivocada.
Luna té unes altres condicions: per damunt dels 272.000 tokens d’entrada, duplica la tarifa d’entrada i multiplica la de sortida per 1,5 en tota la petició. Per entendre el consum hem de veure la tarifa efectiva, no només els cèntims de la primera fila.
Per què el percentatge de quota pot avançar més que el comptador
Un percentatge necessita una referència. A Claude Code, l’ocupació del context relaciona l’entrada i la memòria cau amb la finestra del model. Els percentatges dels límits de cinc hores i de set dies són camps diferents. Un 30% més de tokens de text no es tradueix automàticament en un 30% més de quota consumida.
Una mesura d’Inventive HQ, del 2 al 4 d’octubre, ajuda a entendre la diferència. En un compte Pro amb diversos models, el recompte final acumulava uns 30,3 milions de tokens, sense les lectures de memòria cau. Si les hi afegim, les categories publicades sumen uns 697,4 milions: aproximadament 23 vegades el recompte. Aquella activitat havia consumit un 33% de la quota setmanal.
Llegir contingut de la memòria cau costa menys. Processar 23 vegades més tokens dels que mostra aquell comptador no vol dir pagar 23 vegades més. L’autor va estimar uns 214 dòlars a tarifes d’API per a aquell consum; no era cap factura addicional de la subscripció. No va establir una conversió universal entre tokens i percentatge, i el pes específic de Luna en la quota encara quedava per determinar.
A Luna, un milió de tokens de sortida pesa cinc vegades més
El total de tokens tampoc ens diu tot el consum de crèdits. Els preus de Codex assignen a Luna 2,5 crèdits per milió d’entrada Standard, 0,25 d’entrada en memòria cau i 12,5 de sortida. El mateix nombre de tokens pesa cinc vegades més si és sortida en lloc d’entrada sense memòria cau.
Si el comptador ajunta l’entrada i la sortida en un sol número, aquesta diferència no es veu. Si la barra de quota tampoc explica com pondera el consum, costa més interpretar-lo. Veiem créixer el percentatge sense tenir el detall necessari per comprovar la suma.
També cal saber quina activitat se suma
Una prova de Luna amb Codex 0.155.1 va verificar que cada agent tenia un comptador independent. El cost equivalent d’API de l’agent principal era de 2,67 dòlars; amb els quatre subagents, de 5,62: un 110,5% més de cost estimat en sumar tot l’equip. No és un augment causat pel tokenitzador ni una factura real, i depèn d’aquella versió.
La sortida inclou el raonament intern, encara que el text que veiem sigui curt. No l’hem de tornar a sumar. Amb la compactació de Claude al servidor, en beta, els totals principals deixen fora la iteració que resumeix el context. Cal sumar usage.iterations per recollir tot el consum.
El 30% addicional de Haiku per al mateix text està documentat. Els casos de Codex mostren altres problemes de comptabilitat i ponderació. Cadascun mereix una explicació completa de què es cobra o es descompta, mantenint clares les diferents causes.
Jo demanaria un recompte comparable per al mateix contingut, totes les categories de consum a la vista i una explicació de com aquest consum fa avançar la quota. Si canvien la unitat o el pes que hi assignen, aquesta diferència ha de sortir al costat del preu anunciat.
El parany apareix quan s’anuncia la baixada del preu per token sense deixar igual de clar que la mateixa feina consumeix més unitats o pesa més del que sembla al comptador. La rebaixa és fàcil de veure. Comprovar el cost complet demana més feina a l’usuari.
Fonts comprovades el 10 d’octubre de 2026. La fotografia de portada és una imatge conceptual generada amb IA; no mostra una factura real.
