A context window, os tokens e a factura, medidos

O malentendido máis caro deste negocio é pensar que un modelo lembra unha conversa.

Non a lembra, e o mecanismo do Capítulo 13 di exactamente por que. O estado dun transformer durante a xeración é a KV cache: as claves e os valores calculados para cada token da secuencia. Esa caché vive durante unha única solicitude. Cando a solicitude remata, o proceso que a tiña pode atender a outra persoa, e a caché desaparece. Non hai un almacén por usuario do outro lado, nin sesión.

Así que a seguinte solicitude ten que chegar levando todo o que se supón que o modelo debe saber, e o modelo reconstrúe ese estado executando unha pasada cara adiante sobre todo o prompt antes de emitir un só token novo. O Capítulo 15 chamou o prompt «todo o estado». Esta é a razón física: o prompt é o estado completo porque nada máis sobrevive á chamada.

A context window é a lonxitude máxima dese prompt máis a súa resposta. É un teito sobre canto estado podes reconstruír, non un contedor que garde nada entre solicitudes. Chamarlle «a memoria do modelo» inviste a causalidade: non estás enchendo unha memoria, estás pagando por restablecela.

De aí vén o vinte e dous. A quenda $n$ leva todas as $n-1$ quendas anteriores, así que o input total ao longo dunha conversa de $n$ quendas é a suma dunha serie crecente, que é cuadrática:

onde $s$ é o system prompt e $h_i$ o historial na quenda $i$. Axustar o input acumulado medido a $an^2 + bn$ ao longo das corenta quendas dá $60.22\,n^2 + 432.25\,n$, que predí 113.645 tokens na quenda 40 fronte aos 112.617 medidos. O termo cuadrático domina e o termo lineal é o que o usuario escribiu realmente.

A consecuencia é a frase que cómpre levar deste capítulo: a túa factura medra co cadrado da conversa, non coa última pregunta. As mesmas corenta preguntas feitas sen historial ningún custan $0.066036. Manter o historial custou $0.274386. O historial multiplicou a factura por 4,2, e seguirá multiplicándoa, porque o multiplicador é a lonxitude da conversa.

A xanela é finita por dúas razóns que empurran na mesma dirección. A primeira é a do Capítulo 9: attention compara cada token con cada outro token, así que o traballo desa capa medra co cadrado da lonxitude da secuencia. A segunda é a memoria: a KV cache medra linealmente coa lonxitude da secuencia, e o Capítulo 13 fixo esa aritmética; en secuencias longas é maior ca os pesos.

Ambos límites foron atacados e ningún foi eliminado. FlashAttention¹ reorganiza o cálculo para que lea e escriba moito menos en memoria de alto ancho de banda, o que fai prácticas as secuencias longas sen cambiar o custo asintótico. Position Interpolation² e YaRN³ amplían a xanela usable dun modelo xa adestrado reescalando as codificacións posicionais do Capítulo 9 no canto de readestralo. Xuntas, son a razón pola que as xanelas pasaron de 2K a 1M en cinco anos.

O que non fixeron foi volver gratuítos os contextos longos. Subiron o teito e suavizaron a pendente. A pendente segue aí, e é o que miden os niveis de prezo máis adiante neste capítulo.

Case todas as calculadoras de custo de internet modelan unha chamada API como input tokens multiplicados por un prezo de entrada máis output tokens multiplicados por un prezo de saída. Iso era certo en 2023. Agora é incorrecto dun xeito que produce facturas desviadas por un factor de dous ou máis nas dúas direccións.

Hai cinco categorías de token facturables:

Tres deses cinco non existían como liñas separadas hai dous anos, e as dúas liñas de caché son as que a xente entende mal, porque unha escritura de caché custa máis ca input ordinario, non menos. Pagas unha prima por gardar algo para poder pagar un desconto cando o leas de volta, e que iso compense depende por completo de cantas veces o leas.

O cubo de razoamento é o do Capítulo 12, agora cun prezo enriba, e trae un detalle que paga a pena dicir claramente: a documentación de Google di que o prezo «baséase nos thought tokens completos que o modelo precisa xerar, malia que só o resumo sae pola API».⁴ Factúranche tokens que nunca se che transmiten. É o único cubo cuxo contido non podes contar, inspeccionar nin verificar.

Agora a parte que converte isto nun problema de normalización máis ca nun problema de multiplicación. Cada provedor informa destes cubos con nomes distintos e —aquí está a trampa— dous deles usan a mesma palabra para dúas cantidades diferentes.

Colle unha chamada: 4.837 tokens lidos da caché, 110 novos, 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 e input_tokens: 110. Ambos campos son a conta de input tokens para o mesmo prompt. O de OpenAI inclúe os tokens en caché; o de Anthropic exclúeos: a súa documentación declara a identidade de forma explícita, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ input_tokens en Anthropic significa «os tokens despois do teu último punto de corte de caché».

E mira a saída. OpenAI e Anthropic informan ambos 442, que xa contén os 300 reasoning tokens. Gemini informa 142 e pon os 300 nun campo propio. O Capítulo 12 sinalou isto como unha incompatibilidade entre dúas maneiras de contar o mesmo traballo; aquí ves o que custa.

Un normalizador son trinta liñas e non é 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
  };
};

Pasa os tres payloads de arriba polos tres lectores e os tres producen o mesmo Usage, e polo tanto o mesmo número: $0.006491. Ese acordo é todo o sentido de escribir a capa.

Se o fas mal, isto é o que custa na mesma chamada:

O terceiro é o perigoso, porque falla en silencio na dirección das boas novas. O teu panel mostra un modelo de razoamento custando menos da metade do que custa, e nada en ningures lanza un erro.

Cos cubos normalizados, a función de custo é curta. A única parte non obvia é a busca de nivel, que explica a seguinte sección:

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);
}

Hai dúas decisións de deseño aí que paga a pena defender. Os fallbacks —prezos de caché que caen ao input, razoamento que cae á saída— codifican o que significa que falte unha táboa: os reasoning tokens en Gemini factúranse á tarifa de saída, así que un prezo reasoning ausente non é cero, é o prezo de saída. E contextSize suma os tres cubos de input no canto só dos novos, porque o nivel escóllese pola lonxitude do prompt, non por canto del che cobraron a prezo completo.

Unha prompt cache garda o estado calculado polo modelo para un prefixo do teu prompt, de modo que unha solicitude posterior co mesmo prefixo evita recalculalo. Da palabra «prefixo» seguen catro propiedades, e as catro sorprenden.

O punto de equilibrio é pequeno dabondo para telo na cabeza, e a documentación de OpenAI fai a aritmética: escribir un prefixo unha vez e reutilizalo unha vez custa 1,35× o seu custo de input ordinario, fronte a 2× por procesalo dúas veces sen caché; ao longo de dez solicitudes, unha escritura e nove lecturas custan 2,15× fronte a 10×. Unha soa reutilización paga a escritura. Anthropic chega ao mesmo sitio: unha lectura para a caché de cinco minutos, dúas para a dunha hora.

Agora a conversa de corenta quendas outra vez, coa caché activada e o prefixo estable:

Un sesenta e oito por cento máis barata, e tres números desa táboa merecen atención.

A caché non entra ata a quenda 6. O prompt non chega aos 1.024 tokens ata entón, así que as primeiras cinco quendas factúranse exactamente como antes; e a sexta factúrase peor, coa prima de escritura de 1,25×, porque é a quenda que enche a caché. A primeira lectura chega na quenda 7. Os 2.887 tokens sen caché da táboa son a aritmética: cinco quendas, non seis. A caché é un desconto en prompts longos, e unha conversa curta non saca nada dela.

A prima de escritura é $0.002474, que é o 2,8 % da factura con caché. Cada quenda escribe a súa cola nova, corenta veces, e toda a prima de escritura é un redondeo fronte ao que aforraron as lecturas. Cómpre entender con precisión o cargo de escritura para deixar de preocuparte por el.

Só 2.887 tokens cobraronse ao prezo completo de input dun total de 112.617. Esa é a forma dunha caché que funciona: case todo é unha lectura.

Aquí tes o fallo que custa diñeiro real, e é un bug dunha liña.

Pon algo que cambie en cada chamada preto do principio do prompt —un timestamp, un ID de solicitude, o nome do usuario, unha liña de «hoxe é», un documento acabado de recuperar— e o prefixo difire desde o byte un. Nada fai match. Cada chamada é un fallo. E como cada chamada presenta un prefixo novo, cada chamada tamén escribe.

A mesma conversa, as mesmas corenta quendas, prompt caching activado, cun timestamp por chamada na parte superior do system prompt:

Activar prompt caching fixo a conversa un vinte por cento máis cara ca non activalo. Pagaches a prima de escritura de 1,25× sobre 109.730 tokens e liches de volta cero. Non hai erro, non hai aviso, e a funcionalidade está acesa.

Así que a regra, e é todo prompt caching nunha soa liña: contido estable diante, contido variable detrás. Instrucións do sistema, definicións de ferramentas e material de referencia primeiro; timestamps, identidade do usuario e a pregunta actual ao final. Anthropic explicita a xerarquía: a caché segue tools → system → messages, e un cambio en calquera nivel invalida ese nivel e todo o que vén despois, así que editar unha soa descrición dunha ferramenta invalida toda a caché.⁵

Dúas consecuencias coas que a xente adoita tropezar. Cambiar que ferramentas están activadas cambia as definicións das ferramentas, así que unha feature flag que engade unha ferramenta para algúns usuarios parte a túa caché en dúas. E en Anthropic, activar ou desactivar a busca web ou as citas modifica o system prompt, o que invalida as cachés de sistema e de mensaxes sen que ti toques unha soa liña do teu propio texto.

A resposta obvia a unha factura cuadrática é deixar de enviar todo o historial: quedar coas últimas doce mensaxes e soltar o resto. Reduce a factura, e adoita ser a decisión equivocada, e a medición di por que.

Truncar a unha xanela de doce mensaxes é un 57 % máis barato ca enviar todo sen caché: a comparación que fai todo o mundo, e a razón pola que a técnica é popular. Pero é un 39 % máis caro ca enviar todo cunha caché que funciona, e activar a caché xunto coa truncación empeórao un pouco no canto de melloralo.

O mecanismo volve ser o prefixo. Unha xanela deslizante elimina a mensaxe máis antiga en cada quenda, así que o prompt xa non comeza onde comezaba a vez anterior e cada quenda presenta un prefixo novo. A guía de OpenAI di exactamente isto: «summarisation, compaction, or context truncation can change the prefix and reset cache reuse».⁶ Na quenda 40, o prompt en xanela ten 813 tokens, por debaixo do mínimo de 1.024 tokens, así que non se pode gardar en caché.

E o diñeiro é a metade barata do custo. O que soltaches é a instrución que o usuario deu na quenda 2 e que o modelo precisaba na quenda 40. A truncación cambia unha factura que podes ver por un fallo que non podes, e facelo ben —compactación, notas estruturadas gardadas fóra da xanela, recuperación de historial baixo demanda— é o tema do Capítulo 24.

Os contextos longos non son máis caros só porque sexan máis longos. Pasado un limiar, son máis caros por token, e o limiar aplícase retroactivamente a todo o prompt.

A páxina de modelo de OpenAI para gpt-5.6-terra dilo nunha frase: «Os prompts con >272K input tokens teñen prezo de 2× para input e 1,5× para output en toda a solicitude».⁷ Non para o exceso. Para todo.

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

Un token, cincuenta e cinco céntimos. Se o teu servizo constrúe prompts a partir de documentos recuperados cuxo tamaño non controlas, tes un precipicio no teu modelo de custos nunha fronteira que ninguén do teu equipo deixou escrita.

O prezo de Google funciona igual cun limiar de 200.000 tokens: Gemini 2.5 Pro custa $1.25 por millón de input tokens para prompts ata 200K e $2.50 por riba, coa saída pasando de $10.00 a $15.00.⁸ Anthropic foi na outra dirección: a 6 de setembro de 2026, a súa documentación indica que Claude 4.6 e posteriores inclúen a context window completa dun millón de tokens ao prezo estándar, así que «unha solicitude de 900k tokens factúrase á mesma tarifa por token ca unha de 9k tokens».⁹ Os modelos anteriores mantiñan o recargo.

Por iso un prezo non é un número. Un prezo é unha táboa de niveis indexada pola lonxitude do prompt, que é para o que serve Tier[] na función de custo, e é a razón pola que computeCost escolle o nivel usando todo o prompt no canto de cada cubo por separado.

Os cinco cubos encaixan nas dúas fases do Capítulo 13, e cando ves o encaixe as ratios de prezo deixan de parecer arbitrarias.

Os input tokens son prefill. Todo o prompt pasa polo modelo nunha soa pasada, procesado en paralelo: grandes multiplicacións de matrices, limitadas polo cómputo. O custo por token é baixo, e esta é a fase que fixa o time to first token: un prompt de 4.947 tokens ten 4.947 tokens de prefill por facer antes de que apareza a primeira palabra.

Os output tokens son decode. Prodúcense un a un, cada un cunha pasada cara adiante completa que le toda a KV cache, coa GPU agardando máis pola memoria ca calculando. Esta é a fase que fixa os tokens per second, non se pode paralelizar dentro dunha única resposta, e é a razón pola que a saída custa arredor de seis veces o input no modelo taxado aquí: $12.00 fronte a $2.00 por millón de tokens.

Tres consecuencias seguen directamente. Unha lectura de caché substitúe traballo de prefill, así que compra latencia e diñeiro á vez: o mesmo desconto aparece como unha factura menor e unha espera máis curta polo primeiro token. Os reasoning tokens son decode que nunca ves, e por iso un modelo de razoamento non emite nada durante varios segundos e despois responde axiña: o Capítulo 12 avisou da consecuencia na interface, e esta é a consecuencia na factura. E abortar un stream non detén a xeración: o Capítulo 14 construíu a cancelación e deixou o prezo para este capítulo, e o prezo é a conta completa de saída, porque os tokens prodúcense e factúranse escoite alguén ou non. O mesmo vale para a resposta que ninguén conserva: rexenerar cinco veces unha resposta da quenda 40 custa $0.057990 pola única que queda na pantalla.

O tokenizer do Capítulo 7 era Python e quedou alí. Orzar acontece no servidor que constrúe a solicitude, así que ten que acontecer aquí, e hai exactamente tres niveis de precisión dispoñibles.

Nivel un: contar localmente. js-tiktoken trae as mesmas táboas de fusión BPE ca o tiktoken de Python, así que dá unha conta idéntica byte a byte para as codificacións de OpenAI, sen chamada de rede:

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);
}

As dúas constantes importan, e son onde as contas locais se desvían. O teu texto non é o que se tokeniza: o modelo de chat do Capítulo 11 envolve primeiro cada mensaxe con marcadores de rol, e eses son tokens polos que pagas. Catro por mensaxe e tres para o priming da resposta é a aproximación convencional nos modelos de chat de OpenAI; nas oitenta e unha mensaxes da conversa anterior suman 324 tokens, o 6,4 % da súa lonxitude. As contas aquí contrastáronse co tiktoken de Python do Capítulo 7 nas oitenta e unha cadeas e son idénticas.

Nivel dous: preguntar ao provedor. Anthropic expón /v1/messages/count_tokens e Google expón count_tokens; ambos aceptan a mesma forma de solicitude ca unha chamada real e devolven gratis unha conta de input tokens. Úsaos cando non poidas contar localmente, e non podes contar localmente para Anthropic, porque o seu tokenizer non está publicado. A documentación de Anthropic é coidadosa sobre o que che dá: a conta «é unha estimación», e «pode incluír tokens engadidos automaticamente por Anthropic para optimizacións do sistema», polos que «non se che factura».¹⁰

Nivel tres: ler usage na resposta. Esa é a verdade, e chega despois de gastar o diñeiro. Xusto por iso existen os dous primeiros niveis: para decidir se enviar a solicitude, non para facturala.

Catro partidas que non aparecen como partidas.

O system prompt, pagado en cada chamada. O de arriba ten 192 tokens co seu overhead de modelo. Ao longo de corenta chamadas son 7.680 tokens: o 5,6 % de toda a factura desta conversa, por oito liñas escritas unha vez. Tamén é o mellor candidato posible para caché, porque é estable e vai primeiro.

Definicións de ferramentas. O nome, a descrición e o esquema JSON de cada ferramenta saen en cada solicitude, e os provedores engaden andamiaxe por riba. Anthropic publica o número: activar ferramentas xa engade un system prompt oculto de 496 tokens en Claude Sonnet 4.5 con tool_choice establecido en auto, ou 588 con any ou unha ferramenta con nome.⁹ Iso é antes dos teus propios esquemas. O Capítulo 18 constrúe o catálogo; o Capítulo 24 mide o que come.

Cada xeración, incluídas as que descartas. Cinco rexeneracións custan cinco veces. O chat mostra unha.

Pensamentos que non se che amosan. A facturación baséase nos thought tokens completos aínda que só se devolve un resumo, e ningunha contabilidade túa pode auditar ese número.

Unha advertencia para pechar, porque é o seguinte pensamento natural e a resposta non é a obvia.

Unha xanela dun millón de tokens non significa un millón de tokens útiles. A precisión da recuperación degrádase coa posición: Liu et al. descubriron que os modelos localizan información de forma fiable ao principio e ao final dun input longo, e moito menos no medio.¹¹ Unha xanela máis grande compra a capacidade de enviar máis, non a certeza de que vaia lerse.

Ese fenómeno mídese unha vez neste curso —a taxa de recuperación en nove posicións no mesmo prompt de 853 tokens— e pertence ao Capítulo 24, onde cambia o que fai un agent. Cítase aquí porque cambia o que deberías comprar: o token máis barato é o que non enviaches.

Agora podes predicir canto custará unha chamada antes de facela, ler canto custou despois e distinguir entre as dúas cousas. Iso cobre todo sobre a solicitude salvo a parte que aínda non tocaches: os mandos.

O Capítulo 17 é sampling: temperature, top-p, top-k, as penalizacións e o determinismo que non tes. Comeza desmontando o erro máis estendido do sector, que temperature é un dial de creatividade. Non o é: temperature divide os logits do Capítulo 4 antes da softmax, e subila non volve o modelo imaxinativo; aumenta a probabilidade dos tokens que o propio modelo puntuou como peores. A partir de aí, por que greedy decoding produce texto mediblemente peor ca sampling, por que top-k e top-p fallan en formas opostas de distribución, e o experimento que pecha o capítulo: vinte pasadas cara adiante idénticas con temperature 0 volven idénticas bit a bit cando o modelo corre só, e poñer o mesmo prompt nun batch xunto ás solicitudes doutra persoa move o 97 % dos seus logits.

Non todas coinciden. A razón empeza co cadro de coma flotante do Capítulo 2.

Todos os prezos, limiares e multiplicadores deste capítulo léronse nas páxinas dos propios provedores o 6 de setembro de 2026 e indícanse con esa data porque van cambiar. O método importa máis ca os números: os cubos, a regra do prefixo e a aritmética de niveis levan dous anos estables mentres todas as cifras se moveron.

A clase 2 de Stanford CS336, Resource accounting, é o tratamento académico máis próximo deste material e a seguinte lectura axeitada: fai a mesma aritmética no lado do adestramento que este capítulo fai no lado da inferencia. As contas de token aquí producíronse con js-tiktoken 1.0.21 usando as codificacións o200k_base e cl100k_base, sobre unha conversa de corenta quendas e 5.090 tokens; o overhead de modelo por mensaxe é a aproximación convencional de catro máis tres e indícase alí onde se inclúe. As cifras de caché, niveis e truncación son as regras de prezo documentadas aplicadas a esas contas de token medidas, non observacións de respostas API en vivo: non se fixo ningunha chamada de pago para producir este capítulo, que tamén é a razón honesta pola que as afirmacións de latencia son cualitativas e as de custo non.