El context window, els tokens i la factura, mesurats

El malentès més car d’aquest negoci és pensar que un model recorda una conversa.

No ho fa, i el mecanisme del capítol 13 explica exactament per què. L’estat d’un transformer durant la generació és la KV cache: les claus i els valors calculats per a cada token de la seqüència. Aquesta cache viu durant una sola request. Quan la request acaba, el procés que la mantenia queda lliure per servir algú altre, i la cache desapareix. A l’altra banda no hi ha cap magatzem per usuari, ni cap sessió.

Per tant, la request següent ha d’arribar portant tot el que se suposa que el model ha de saber, i el model reconstrueix aquest estat executant un forward pass sobre tot el prompt abans d’emetre un sol token nou. El capítol 15 anomenava el prompt «tot l’estat». Aquesta n’és la raó física: el prompt és l’estat complet perquè res més no sobreviu a la call.

El context window és la llargada màxima d’aquest prompt més la seva resposta. És un sostre sobre quant estat pots reconstruir, no un contenidor que guardi res entre requests. Anomenar-lo «la memòria del model» inverteix la direcció de la causalitat: no estàs omplint una memòria, estàs pagant per restablir-ne una.

D’aquí surt el vint-i-dos. El torn $n$ porta tots els $n-1$ torns anteriors, de manera que l’input total al llarg d’una conversa de $n$ torns és la suma d’una sèrie creixent, que és quadràtica:

on $s$ és el system prompt i $h_i$ l’historial al torn $i$. Ajustar l’input acumulat mesurat a $an^2 + bn$ al llarg dels quaranta torns dona $60.22\,n^2 + 432.25\,n$, que prediu 113.645 tokens al torn 40 contra 112.617 de mesurats. El terme quadràtic domina, i el terme lineal és el que l’usuari ha escrit realment.

La conseqüència és la frase que cal endur-se d’aquest capítol: la teva factura creix amb el quadrat de la conversa, no amb l’última pregunta. Les mateixes quaranta preguntes fetes sense cap historial costen $0.066036. Mantenir l’historial costa $0.274386. L’historial va multiplicar la factura per 4,2, i la continuarà multiplicant, perquè el multiplicador és la llargada de la conversa.

La window és finita per dos motius que empenyen en la mateixa direcció. El primer és el del capítol 9: attention compara cada token amb tots els altres tokens, de manera que la feina d’aquesta capa creix amb el quadrat de la llargada de la seqüència. El segon és la memòria: la KV cache creix linealment amb la llargada de la seqüència, i el capítol 13 en va fer l’aritmètica; en seqüències llargues és més gran que els pesos.

S’ha atacat tots dos límits i no se n’ha eliminat cap. FlashAttention¹ reorganitza el càlcul perquè llegeixi i escrigui molt menys a la memòria d’alta amplada de banda, cosa que fa pràctiques les seqüències llargues sense canviar el cost asimptòtic. Position Interpolation² i YaRN³ estenen la window usable d’un model entrenat reescalant els positional encodings del capítol 9 en lloc de reentrenar-lo. Junts expliquen per què les windows han passat de 2K a 1M en cinc anys.

El que no han fet és tornar gratuïts els contexts llargs. Han apujat el sostre i han suavitzat el pendent. El pendent encara hi és, i és el que mesuren els tiers de preu més endavant en aquest capítol.

Gairebé totes les calculadores de costos d’internet modelen una API call com input tokens multiplicats per un preu d’input més output tokens multiplicats per un preu d’output. Això era cert el 2023. Ara és incorrecte d’una manera que produeix factures desviades per un factor de dos o més en totes dues direccions.

Hi ha cinc categories de tokens facturables:

Tres d’aquests cinc no existien com a línies separades fa dos anys, i les dues línies de cache són les que la gent entén malament, perquè una escriptura de cache costa més que l’input ordinari, no menys. Pagues una prima per emmagatzemar una cosa per poder pagar un descompte quan la tornes a llegir, i si surt a compte depèn completament de quantes vegades la llegeixes.

El compartiment de reasoning és el del capítol 12, ara amb un preu, i porta un detall que val la pena dir clarament: la documentació de Google diu que el preu «es basa en tots els thought tokens que el model necessita generar, tot i que només el resum surt de l’API».⁴ Se’t facturen tokens que no se’t transmeten mai. És l’únic compartiment el contingut del qual no pots comptar, inspeccionar ni verificar.

Ara ve la part que converteix això en un problema de normalització i no de multiplicació. Cada provider informa d’aquests compartiments amb noms diferents i —aquest és el parany— dos fan servir la mateixa paraula per a dues quantitats diferents.

Agafa una call: 4.837 tokens llegits de cache, 110 de nous, 142 output tokens visibles, 300 reasoning tokens.

// OpenAI-compatible
{ "usage": { "prompt_tokens": 4947,
             "prompt_tokens_details": { "cached_tokens": 4837 },
             "completion_tokens": 442,
             "completion_tokens_details": { "reasoning_tokens": 300 } } }

// Anthropic
{ "usage": { "input_tokens": 110,
             "cache_read_input_tokens": 4837,
             "cache_creation_input_tokens": 0,
             "output_tokens": 442 } }

// Gemini
{ "usageMetadata": { "promptTokenCount": 4947,
                     "cachedContentTokenCount": 4837,
                     "candidatesTokenCount": 142,
                     "thoughtsTokenCount": 300 } }

Mira prompt_tokens: 4947 i input_tokens: 110. Tots dos camps són el recompte d’input tokens del mateix prompt. El d’OpenAI inclou els cached tokens; el d’Anthropic els exclou: la seva documentació declara la identitat explícitament, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ input_tokens d’Anthropic vol dir «els tokens després del teu darrer punt de ruptura de cache».

I mira l’output. OpenAI i Anthropic informen tots dos de 442, que ja conté els 300 reasoning tokens. Gemini informa de 142 i posa els 300 en un camp propi. El capítol 12 assenyalava això com una incompatibilitat entre dues maneres de comptar la mateixa feina; aquí tens el que costa.

Un normalitzador són trenta línies i no és opcional:

export interface Usage {
  promptTokens?: number;        // input, NOT cached
  cachedInputTokens?: number;   // read from cache
  cacheWriteTokens?: number;    // written to cache on this call
  completionTokens?: number;    // output
  reasoningTokens?: number;     // billed apart from output (Gemini only)
}

const num = (v: unknown) => (typeof v === "number" && isFinite(v) ? v : 0);

export const fromOpenAI = (raw: any): Usage => {
  const u = raw.usage ?? {}, d = u.prompt_tokens_details ?? {};
  const cached = num(d.cached_tokens), write = num(d.cache_write_tokens);
  return {
    promptTokens: Math.max(0, num(u.prompt_tokens) - cached - write), 
    cachedInputTokens: cached,
    cacheWriteTokens: write,
    completionTokens: num(u.completion_tokens),   // reasoning already inside
    reasoningTokens: 0,
  };
};

export const fromAnthropic = (raw: any): Usage => {
  const u = raw.usage ?? {};
  return {
    promptTokens: num(u.input_tokens),            // already excludes cache
    cachedInputTokens: num(u.cache_read_input_tokens),
    cacheWriteTokens: num(u.cache_creation_input_tokens),
    completionTokens: num(u.output_tokens),
    reasoningTokens: 0,
  };
};

export const fromGemini = (raw: any): Usage => {
  const m = raw.usageMetadata ?? {}, cached = num(m.cachedContentTokenCount);
  return {
    promptTokens: Math.max(0, num(m.promptTokenCount) - cached),
    cachedInputTokens: cached,
    cacheWriteTokens: 0,
    completionTokens: num(m.candidatesTokenCount), // EXCLUDES thinking
    reasoningTokens: num(m.thoughtsTokenCount),    // billed at output rate
  };
};

Passa els tres payloads anteriors pels tres readers i tots tres produeixen el mateix Usage i, per tant, el mateix número: $0.006491. Aquest acord és tot el sentit d’escriure la capa.

Si t’equivoques, això és el que costa, en la mateixa call:

El tercer és el perillós, perquè falla en silenci en la direcció de les bones notícies. El teu dashboard mostra un model de reasoning que costa menys de la meitat del que costa, i enlloc no salta cap error.

Amb els compartiments normalitzats, la funció de cost és curta. L’única part no òbvia és la cerca del tier, que explica la secció següent:

export interface Tier { maxPromptTokens: number | null; price: number }
export interface Pricing {
  input: Tier[]; output: Tier[];
  cachedInput?: Tier[]; cacheWrite?: Tier[]; reasoning?: Tier[];
}

const tierPrice = (tiers: Tier[] | undefined, contextSize: number, fallback?: Tier[]) => {
  const table = tiers ?? fallback;
  if (!table?.length) return 0;
  const sorted = [...table].sort(
    (a, b) => (a.maxPromptTokens ?? Infinity) - (b.maxPromptTokens ?? Infinity));
  for (const t of sorted)
    if (t.maxPromptTokens === null || contextSize <= t.maxPromptTokens) return t.price;
  return sorted[sorted.length - 1].price;
};

export function computeCost(pricing: Pricing, usage: Usage): number {
  const fresh = usage.promptTokens ?? 0;
  const read  = usage.cachedInputTokens ?? 0;
  const write = usage.cacheWriteTokens ?? 0;
  const out   = usage.completionTokens ?? 0;
  const think = usage.reasoningTokens ?? 0;
  const contextSize = fresh + read + write;   // the tier depends on the WHOLE prompt
  return fresh * tierPrice(pricing.input, contextSize)
       + read  * tierPrice(pricing.cachedInput, contextSize, pricing.input)
       + write * tierPrice(pricing.cacheWrite,  contextSize, pricing.input)
       + out   * tierPrice(pricing.output, contextSize)
       + think * tierPrice(pricing.reasoning, contextSize, pricing.output);
}

Hi ha dues decisions de disseny que val la pena defensar. Els fallbacks —els preus de cache que tornen a input, reasoning que torna a output— codifiquen què vol dir que falti una taula: els reasoning tokens a Gemini es facturen a la tarifa d’output, així que un preu reasoning absent no és zero, és el preu d’output. I contextSize suma tots tres compartiments d’input, no només els frescos, perquè el tier es tria per la llargada del prompt, no per quina part se t’ha cobrat a preu complet.

Una prompt cache emmagatzema l’estat calculat del model per a un prefix del teu prompt, de manera que una request posterior amb el mateix prefix salta el recàlcul. De la paraula «prefix» se’n desprenen quatre propietats, i totes quatre sorprenen.

El punt d’equilibri és prou petit per tenir-lo al cap, i la documentació d’OpenAI en fa l’aritmètica: escriure un prefix una vegada i reutilitzar-lo una vegada costa 1,35× el seu cost d’input ordinari, contra 2× de processar-lo dues vegades sense cache; en deu requests, una escriptura i nou lectures costen 2,15× contra 10×. Una sola reutilització paga l’escriptura. Anthropic arriba al mateix lloc: una lectura per a la cache de cinc minuts, dues per a la cache d’una hora.

Ara la conversa de quaranta torns una altra vegada, amb caching activat i el prefix estable:

Un seixanta-vuit per cent més barat, i tres números d’aquesta taula mereixen atenció.

La cache no entra en joc fins al torn 6. El prompt no arriba als 1.024 tokens fins aleshores, de manera que els primers cinc torns es facturen exactament com abans, i el sisè es factura pitjor, amb la prima d’escriptura d’1,25×, perquè és el torn que omple la cache. La primera lectura arriba al torn 7. Els 2.887 tokens no cachejats de la taula són l’aritmètica: cinc torns, no sis. El caching és un descompte sobre prompts llargs, i una conversa curta no en treu res.

La prima d’escriptura és $0.002474, que és el 2,8 % de la factura cachejada. Cada torn escriu la seva cua nova, quaranta vegades, i tota la prima d’escriptura és un arrodoniment al costat del que han estalviat les lectures. Val la pena entendre la càrrega d’escriptura amb precisió perquè deixis de preocupar-te’n.

Només 2.887 tokens s’han cobrat a preu d’input complet dels 112.617. Aquesta és la forma d’una cache que funciona: gairebé tot és una lectura.

Aquí tens la fallada que costa diners de debò, i és un bug d’una línia.

Posa alguna cosa que canvia a cada call prop del principi del prompt —un timestamp, un request id, el nom de l’usuari, una línia «avui és», un document acabat de recuperar— i el prefix difereix des del primer byte. Res no coincideix. Cada call és un miss. I com que cada call presenta un prefix nou, cada call també escriu.

La mateixa conversa, els mateixos quaranta torns, caching activat, amb un timestamp per call al capdamunt del system prompt:

Activar prompt caching va fer que la conversa fos un vint per cent més cara que no activar-lo. Vas pagar la prima d’escriptura d’1,25× sobre 109.730 tokens i no vas llegir res. No hi ha error, no hi ha avís, i la funció està activada.

Així que la regla, i és tot el prompt caching en una línia: contingut estable davant, contingut variable darrere. Instruccions de sistema, definicions d’eines i material de referència primer; timestamps, identitat de l’usuari i la pregunta actual al final. Anthropic fa explícita la jerarquia: la cache segueix tools → system → messages, i un canvi a qualsevol nivell invalida aquell nivell i tot el que ve després, de manera que editar una sola descripció d’eina invalida tota la cache.⁵

Dues conseqüències fan entrebancar la gent. Canviar quines eines estan activades canvia les definicions d’eines, així que un feature flag que afegeix una eina per a alguns usuaris parteix la cache en dues. I a Anthropic, activar o desactivar la cerca web o les cites modifica el system prompt, cosa que invalida les caches de sistema i de missatges sense que hagis tocat ni una línia del teu propi text.

La resposta òbvia a una factura quadràtica és deixar d’enviar tot l’historial: conservar la darrera dotzena de missatges i descartar la resta. Redueix la factura, i normalment és el moviment equivocat, i la mesura explica per què.

Retallar a una window de dotze missatges és un 57 % més barat que enviar-ho tot sense cache: la comparació que fa tothom i el motiu pel qual la tècnica és popular. Però és un 39 % més car que enviar-ho tot amb una cache que funciona, i activar caching juntament amb truncation ho empitjora lleugerament en lloc de millorar-ho.

El mecanisme torna a ser el prefix. Una sliding window elimina el missatge més antic a cada torn, de manera que el prompt ja no comença on començava l’última vegada i cada torn presenta un prefix nou. La guia d’OpenAI diu exactament això: «la summarisation, la compaction o la context truncation poden canviar el prefix i reiniciar la reutilització de cache».⁶ Al torn 40, el prompt en window és de 813 tokens, per sota del mínim de 1.024 tokens, així que no es pot cachejar gens.

I els diners són la meitat barata del cost. El que has descartat és la instrucció que l’usuari va donar al torn 2 i que el model necessitava al torn 40. Truncation intercanvia una factura que pots veure per una fallada que no pots veure, i fer-ho bé —compaction, notes estructurades fora de la window, recuperar historial sota demanda— és el tema del capítol 24.

Els contexts llargs no són més cars només perquè són més llargs. Passat un llindar, són més cars per token, i el llindar s’aplica retroactivament a tot el prompt.

La pàgina de model d’OpenAI per a gpt-5.6-terra ho diu en una frase: «Els prompts amb >272K input tokens tenen un preu de 2× input i 1,5× output per a tota la request».⁷ No per l’excés. Per tot.

prompt 271,999 + 500 output  ->  $0.5500
prompt 272,000 + 500 output  ->  $0.5500
prompt 272,001 + 500 output  ->  $1.0970

Un token, cinquanta-cinc cèntims. Si el teu servei construeix prompts a partir de documents recuperats que no controles en mida, tens un precipici al teu model de costos en una frontera que ningú del teu equip no ha escrit.

El preu de Google funciona de la mateixa manera amb un llindar de 200.000 tokens: Gemini 2.5 Pro costa $1.25 per milió d’input tokens per a prompts fins a 200K i $2.50 per sobre, amb l’output passant de $10.00 a $15.00.⁸ Anthropic va anar en sentit contrari: a 6 de setembre de 2026, la seva documentació afirma que Claude 4.6 i posteriors inclouen tota la window d’un milió de tokens al preu estàndard, així que «una request de 900k tokens es factura a la mateixa tarifa per token que una request de 9k tokens».⁹ Els models anteriors mantenien el recàrrec.

Per això un preu no és un número. Un preu és una taula de tiers indexada per la llargada del prompt, que és per a què serveix Tier[] a la funció de cost, i per això computeCost selecciona el tier fent servir tot el prompt en lloc de cada compartiment per separat.

Els cinc compartiments es corresponen amb les dues fases del capítol 13, i quan veus la correspondència les ràtios de preu deixen de semblar arbitràries.

Els input tokens són prefill. Tot el prompt passa pel model en una sola passada, processat en paral·lel: grans multiplicacions de matrius, limitades pel càlcul. El cost per token és baix, i aquesta és la fase que fixa el temps fins al primer token: un prompt de 4.947 tokens té 4.947 tokens de prefill per fer abans que aparegui la primera paraula.

Els output tokens són decode. Es produeixen d’un en un, cadascun amb un forward pass complet que llegeix tota la KV cache, amb la GPU sobretot esperant la memòria en lloc de calcular. Aquesta és la fase que fixa els tokens per segon, no es pot paral·lelitzar dins d’una sola resposta, i és per això que l’output costa aproximadament sis vegades l’input al model valorat aquí: $12.00 contra $2.00 per milió de tokens.

D’això se’n desprenen directament tres conseqüències. Una lectura de cache substitueix feina de prefill, així que compra latència i diners alhora: el mateix descompte apareix com una factura més baixa i una espera més curta fins al primer token. Els reasoning tokens són decode que no veus, i per això un model de reasoning no stream res durant uns segons i després respon ràpidament: el capítol 12 avisava de la conseqüència d’interfície, i aquesta és la conseqüència a la factura. I aturar un stream no atura la generació: el capítol 14 va construir la cancel·lació i va deixar el preu per a aquest capítol, i el preu és el recompte complet d’output, perquè els tokens es produeixen i es facturen tant si algú escolta com si no. El mateix passa amb la resposta que ningú conserva: regenerar cinc vegades una resposta del torn 40 costa $0.057990 per la que queda a la pantalla.

El tokenizer del capítol 7 era Python i s’hi va quedar. El pressupost es fa al servidor que construeix la request, així que ha de passar aquí, i hi ha exactament tres nivells de precisió disponibles.

Nivell u: comptar localment. js-tiktoken porta les mateixes taules de BPE merge que el tiktoken de Python, així que dona un recompte byte per byte idèntic per als encodings d’OpenAI, sense cap call de xarxa:

import { getEncoding } from "js-tiktoken";

const enc = getEncoding("o200k_base");
const PER_MESSAGE = 4;   // role and delimiters added by the chat template
const PER_REPLY = 3;     // priming for the assistant turn

export function promptTokens(messages: { role: string; content: string }[]) {
  return messages.reduce(
    (sum, m) => sum + enc.encode(m.content).length + PER_MESSAGE, PER_REPLY);
}

Les dues constants importen i són el lloc on els recomptes locals deriven. El teu text no és el que es tokenitza: el chat template del capítol 11 embolcalla cada missatge amb marcadors de rol abans, i aquests són tokens que pagues. Quatre per missatge i tres per preparar la resposta és l’aproximació convencional per als models de chat d’OpenAI; al llarg dels vuitanta-un missatges de la conversa anterior sumen 324 tokens, el 6,4 % de la seva llargada. Els recomptes d’aquí s’han contrastat amb el tiktoken de Python del capítol 7 en totes vuitanta-una cadenes i són idèntics.

Nivell dos: preguntar al provider. Anthropic exposa /v1/messages/count_tokens i Google exposa count_tokens, tots dos acceptant la mateixa forma de request que una call real i retornant gratuïtament un recompte d’input tokens. Fes-los servir quan no puguis comptar localment, i no pots comptar localment per Anthropic, que no publica el tokenizer. La documentació d’Anthropic és curosa sobre què t’està donant: el recompte «és una estimació», i «pot incloure tokens afegits automàticament per Anthropic per a optimitzacions de sistema», pels quals «no se’t factura».¹⁰

Nivell tres: llegir usage a la resposta. Aquesta és la veritat, i arriba després que els diners ja s’hagin gastat. Precisament per això existeixen els dos primers nivells: per decidir si envies la request, no per facturar-la.

Quatre partides que no apareixen com a partides.

El system prompt, pagat a cada call. El d’aquí dalt són 192 tokens amb el seu overhead de plantilla. En quaranta calls són 7.680 tokens: el 5,6 % de tota la factura d’aquesta conversa, per vuit línies escrites una vegada. També és el millor candidat possible per a cache, perquè és estable i va primer.

Definicions d’eines. El nom, la descripció i el JSON schema de cada eina surten a cada request, i els providers hi afegeixen bastida a sobre. Anthropic publica el número: activar eines ja afegeix un system prompt ocult de 496 tokens a Claude Sonnet 4.5 amb tool_choice configurat a auto, o 588 amb any o una eina amb nom.⁹ Això és abans dels teus propis schemas. El capítol 18 construeix el catàleg; el capítol 24 mesura què es menja.

Cada generació, incloses les que descartes. Cinc regeneracions costen cinc vegades. El chat en mostra una.

Pensaments que no se’t mostren. La facturació es basa en tots els thought tokens encara que només es retorni un resum, i cap comptabilitat teva no pot auditar aquest número.

Un avís per tancar, perquè és el pensament natural següent i la resposta no és l’òbvia.

Una window d’un milió de tokens no vol dir un milió de tokens usables. La precisió de retrieval es degrada amb la posició: Liu et al. van trobar que els models localitzen informació de manera fiable al començament i al final d’un input llarg, i molt menys al mig.¹¹ Una window més gran compra la capacitat d’enviar més, no la certesa de ser llegit.

Aquest fenomen es mesura una vegada en aquest curs —la taxa de retrieval en nou posicions dins el mateix prompt de 853 tokens— i pertany al capítol 24, on canvia el que fa un agent. Se cita aquí perquè canvia el que hauries de comprar: el token més barat és el que no has enviat.

Ara pots predir què costarà una call abans de fer-la, llegir què ha costat després, i distingir una cosa de l’altra. Això cobreix tot sobre la request excepte la part que encara no has tocat: els controls.

El capítol 17 és sampling: temperature, top-p, top-k, les penalitzacions i el determinisme que no tens. Comença desmuntant l’error més estès del sector, que temperature és un dial de creativitat. No ho és: temperature divideix els logits del capítol 4 abans de la softmax, i apujar-la no fa imaginatiu el model, sinó que augmenta la probabilitat de tokens que el mateix model ha puntuat com a pitjors. A partir d’aquí, per què greedy decoding produeix text mesuradament pitjor que sampling, per què top-k i top-p fallen en formes oposades de distribució, i l’experiment amb què acaba el capítol: vint forward passes idèntics a temperature 0 tornen idèntics bit a bit quan el model s’executa sol, i posar el mateix prompt en un batch al costat de les requests d’algú altre mou el 97 % dels seus logits.

No coincideixen tots. El motiu comença amb el requadre de coma flotant del capítol 2.

Tots els preus, llindars i multiplicadors d’aquest capítol es van llegir a les pàgines pròpies dels providers el 6 de setembre de 2026 i s’indiquen amb aquesta data perquè canviaran. El mètode importa més que els números: els compartiments, la regla de prefix i l’aritmètica de tiers han estat estables durant dos anys mentre que totes les xifres que contenen s’han mogut.

La classe 2 de Stanford CS336, Resource accounting, és el tractament acadèmic més proper d’aquest material i la lectura següent adequada: fa la mateixa aritmètica al costat de training que aquest capítol fa al costat d’inference. Els recomptes de tokens d’aquí s’han produït amb js-tiktoken 1.0.21 fent servir els encodings o200k_base i cl100k_base, sobre una conversa de quaranta torns de 5.090 tokens; l’overhead de plantilla per missatge és l’aproximació convencional de quatre més tres i s’indica sempre que s’hi inclou. Les xifres de cache, tier i truncation són les regles de preus documentades aplicades a aquells recomptes de tokens mesurats, no observacions de respostes d’API en viu: no s’ha fet cap call de pagament per produir aquest capítol, que també és la raó honesta per la qual les afirmacions de latència són qualitatives i les afirmacions de cost no.