Context window, tokens y factura, medidos

El malentendido más caro de este negocio es creer que un modelo recuerda una conversación.

No lo hace, y el mecanismo del Capítulo 13 explica exactamente por qué. El estado de un transformer durante la generación es la KV cache: las keys y values calculadas para cada token de la secuencia. Esa cache vive durante una única solicitud. Cuando la solicitud termina, el proceso que la tenía queda libre para atender a otra persona, y la cache desaparece. No hay ningún almacén por usuario al otro lado, ni ninguna sesión.

Así que la siguiente solicitud tiene que llegar llevando todo lo que se supone que el modelo debe saber, y el modelo reconstruye ese estado ejecutando un forward pass sobre todo el prompt antes de emitir un solo token nuevo. El Capítulo 15 llamó al prompt «el estado entero». Esta es la razón física: el prompt es el estado completo porque nada más sobrevive a la llamada.

La context window es la longitud máxima de ese prompt más su respuesta. Es un techo sobre cuánto estado puedes reconstruir, no un contenedor que guarde nada entre solicitudes. Llamarla «la memoria del modelo» invierte la causalidad: no estás llenando una memoria, estás pagando por restablecer una.

De ahí sale el veintidós. El turno $n$ arrastra todos los $n-1$ turnos anteriores, así que el input total a lo largo de una conversación de $n$ turnos es la suma de una serie creciente, que es cuadrática:

donde $s$ es el system prompt y $h_i$ el historial en el turno $i$. Ajustar el input acumulado medido a $an^2 + bn$ en los cuarenta turnos da $60.22\,n^2 + 432.25\,n$, que predice 113.645 tokens en el turno 40 frente a 112.617 medidos. El término cuadrático domina y el término lineal es lo que el usuario escribió realmente.

La consecuencia es la frase que conviene llevarse de este capítulo: tu factura crece con el cuadrado de la conversación, no con la última pregunta. Las mismas cuarenta preguntas hechas sin historial alguno cuestan $0.066036. Mantener el historial costó $0.274386. El historial multiplicó la factura por 4,2, y la seguirá multiplicando, porque el multiplicador es la longitud de la conversación.

La window es finita por dos razones que empujan en la misma dirección. La primera es la del Capítulo 9: la attention compara cada token con cada otro token, así que el trabajo de esa capa crece con el cuadrado de la longitud de la secuencia. La segunda es la memoria: la KV cache crece linealmente con la longitud de la secuencia, y el Capítulo 13 ya hizo esas cuentas; en secuencias largas es mayor que los pesos.

Ambos límites han sido atacados y ninguno ha desaparecido. FlashAttention¹ reorganiza el cálculo para que lea y escriba mucho menos en memoria de alto ancho de banda, lo que hace prácticas las secuencias largas sin cambiar el coste asintótico. Position Interpolation² y YaRN³ amplían la window utilizable de un modelo entrenado reescalando los positional encodings del Capítulo 9 en vez de reentrenar. Juntos explican por qué las windows pasaron de 2K a 1M en cinco años.

Lo que no hicieron fue volver gratis los context largos. Hicieron el techo más alto y la pendiente más suave. La pendiente sigue ahí, y es lo que miden los tramos de precio más adelante en este capítulo.

Casi todas las calculadoras de costes de internet modelan una llamada API como input tokens por un precio de input más output tokens por un precio de output. Eso era cierto en 2023. Ahora es incorrecto de una forma que produce facturas desviadas por un factor de dos o más en ambas direcciones.

Hay cinco categorías de token facturables:

Tres de esas cinco no existían como líneas separadas hace dos años, y las dos líneas de cache son las que la gente entiende mal, porque un cache write cuesta más que el input ordinario, no menos. Pagas una prima por almacenar algo para poder pagar un descuento al leerlo de vuelta, y si esa operación compensa depende por completo de cuántas veces lo leas.

El cubo de reasoning es el del Capítulo 12, ahora con precio, y trae un detalle que merece decirse claramente: la documentación de Google dice que el precio «se basa en todos los thought tokens que el modelo necesita generar, aunque la API solo devuelva el resumen».⁴ Se te facturan tokens que nunca se te transmiten. Es el único cubo cuyo contenido no puedes contar, inspeccionar ni verificar.

Ahora viene la parte que convierte esto en un problema de normalización en vez de un problema de multiplicación. Cada proveedor informa de estos cubos con nombres distintos y —esta es la trampa— dos de ellos usan la misma palabra para dos cantidades distintas.

Toma una llamada: 4.837 tokens leídos de cache, 110 nuevos, 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 y input_tokens: 110. Ambos campos son el recuento de input tokens del mismo prompt. El de OpenAI incluye los tokens en cache; el de Anthropic los excluye: su documentación establece explícitamente la identidad, total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens.⁵ El input_tokens de Anthropic significa «los tokens después de tu último punto de corte de cache».

Y mira el output. OpenAI y Anthropic informan ambos de 442, que ya contiene los 300 reasoning tokens. Gemini informa de 142 y pone los 300 en un campo propio. El Capítulo 12 señaló esto como una incompatibilidad entre dos formas de contar el mismo trabajo; aquí está lo que cuesta.

Un normalizador son treinta líneas y no es 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 los tres payloads anteriores por los tres lectores y los tres producen el mismo Usage, y por tanto el mismo número: $0.006491. Ese acuerdo es todo el sentido de escribir la capa.

Si te equivocas, esto es lo que cuesta, en la misma llamada:

El tercero es el peligroso, porque falla en silencio en la dirección de las buenas noticias. Tu dashboard muestra un modelo de reasoning costando menos de la mitad de lo que cuesta, y nada en ninguna parte lanza un error.

Con los cubos normalizados, la función de coste es corta. La única parte no evidente es la búsqueda de tramo, que explica la siguiente 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);
}

Hay dos decisiones de diseño ahí que merece la pena defender. Los fallbacks —precios de cache que caen al input, reasoning que cae al output— codifican qué significa una tabla incompleta: los reasoning tokens en Gemini se facturan a la tarifa de output, así que un precio reasoning ausente no es cero, es el precio de output. Y contextSize suma los tres cubos de input en vez de solo los nuevos, porque el tramo se elige por lo largo que es el prompt, no por qué parte de él se te cobró a precio completo.

Una prompt cache almacena el estado calculado del modelo para un prefijo de tu prompt, de modo que una solicitud posterior con el mismo prefijo se salta recomputarlo. De la palabra «prefijo» se desprenden cuatro propiedades, y las cuatro sorprenden.

El punto de equilibrio es lo bastante pequeño como para recordarlo, y la documentación de OpenAI hace la cuenta: escribir un prefijo una vez y reutilizarlo una vez cuesta 1,35× su coste de input ordinario, frente a 2× por procesarlo dos veces sin cache; en diez solicitudes, una escritura y nueve lecturas cuestan 2,15× frente a 10×. Una reutilización paga la escritura. Anthropic cae en el mismo sitio: una lectura para la cache de cinco minutos, dos para la cache de una hora.

Ahora la conversación de cuarenta turnos otra vez, con caching activado y el prefijo estable:

Un sesenta y ocho por ciento más barato, y hay tres números en esa tabla que merecen atención.

La cache no entra en juego hasta el turno 6. El prompt no llega a 1.024 tokens hasta entonces, así que los cinco primeros turnos se facturan exactamente como antes, y el sexto se factura peor, con la prima de escritura de 1,25\u00d7, porque es el turno que llena la cache. La primera lectura llega en el turno 7. Los 2.887 uncached tokens de la tabla son esa aritmética: el valor de cinco turnos, no de seis. El caching es un descuento sobre prompts largos, y una conversación corta no obtiene nada de él.

La prima de escritura es $0.002474, lo que supone el 2,8 % de la factura con cache. Cada turno escribe su nueva cola, cuarenta veces, y toda la prima de escritura es un error de redondeo frente a lo que ahorraron las lecturas. Conviene entender con precisión el cargo de escritura para dejar de preocuparte por él.

Solo 2.887 tokens se cobraron al precio completo de input de 112.617. Esa es la forma de una cache que funciona: casi todo es una lectura.

Aquí está el fallo que cuesta dinero de verdad, y es un bug de una línea.

Pon algo que cambie en cada llamada cerca del principio del prompt —un timestamp, un request id, el nombre del usuario, una línea de «hoy es», un documento recién recuperado— y el prefijo difiere desde el primer byte. Nada coincide. Cada llamada es un fallo. Y como cada llamada presenta un prefijo nuevo, cada llamada también escribe.

Misma conversación, mismos cuarenta turnos, caching activado, con un timestamp por llamada al principio del system prompt:

Activar prompt caching hizo la conversación un veinte por ciento más cara que no activarlo. Pagaste la prima de escritura de 1,25× sobre 109.730 tokens y no leíste nada de vuelta. No hay error, no hay aviso, y la función está activada.

Así que la regla, y es todo prompt caching en una línea: contenido estable delante, contenido variable detrás. Instrucciones de sistema, definiciones de herramientas y material de referencia primero; timestamps, identidad del usuario y la pregunta actual al final. Anthropic hace explícita la jerarquía: la cache sigue tools → system → messages, y un cambio en cualquier nivel invalida ese nivel y todo lo que viene después, así que editar una sola descripción de herramienta invalida toda la cache.⁵

Dos consecuencias con las que la gente tropieza. Cambiar qué herramientas están habilitadas cambia las definiciones de herramientas, así que un feature flag que añade una herramienta para algunos usuarios divide tu cache en dos. Y en Anthropic, activar o desactivar la búsqueda web o las citas modifica el system prompt, lo que invalida las caches de sistema y mensajes sin que toques una línea de tu propio texto.

La respuesta obvia a una factura cuadrática es dejar de enviar todo el historial: conservar la última docena de mensajes y eliminar el resto. Reduce la factura, y normalmente es la decisión equivocada, y la medición explica por qué.

Truncar a una window de doce mensajes es un 57 % más barato que enviarlo todo sin cache: la comparación que todo el mundo hace, y la razón por la que la técnica es popular. Pero es un 39 % más caro que enviarlo todo con una cache que funciona, y activar caching junto con la truncación lo hace ligeramente peor en vez de mejor.

El mecanismo vuelve a ser el prefijo. Una window deslizante elimina el mensaje más antiguo en cada turno, así que el prompt ya no empieza donde empezó la vez anterior y cada turno presenta un prefijo nuevo. La guía de OpenAI dice exactamente esto: «summarisation, compaction, or context truncation can change the prefix and reset cache reuse».⁶ En el turno 40, el prompt con window mide 813 tokens, por debajo del mínimo de 1.024 tokens, así que no puede cachearse en absoluto.

Y el dinero es la mitad barata del coste. Lo que has eliminado es la instrucción que el usuario dio en el turno 2 y que el modelo necesitaba en el turno 40. La truncación cambia una factura que puedes ver por un fallo que no puedes ver, y hacerlo bien —compaction, notas estructuradas mantenidas fuera de la window, recuperar historial bajo demanda— es el tema del Capítulo 24.

Los context largos no son más caros solo porque sean más largos. Pasado un umbral, son más caros por token, y el umbral se aplica retroactivamente a todo el prompt.

La página de modelo de OpenAI para gpt-5.6-terra lo dice en una frase: «Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request».⁷ No para el 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 y cinco céntimos. Si tu servicio construye prompts a partir de documentos recuperados cuyo tamaño no controlas, tienes un precipicio en tu modelo de costes en una frontera que nadie de tu equipo ha escrito.

Los precios de Google funcionan igual con un umbral de 200.000 tokens: Gemini 2.5 Pro cuesta $1.25 por millón de input tokens para prompts de hasta 200K y $2.50 por encima, con el output pasando de $10.00 a $15.00.⁸ Anthropic fue en la dirección contraria: a 6 de septiembre de 2026, su documentación dice que Claude 4.6 y posteriores incluyen toda la context window de un millón de tokens al precio estándar, así que «a 900k-token request is billed at the same per-token rate as a 9k-token request».⁹ Los modelos anteriores mantenían el recargo.

Por eso un precio no es un número. Un precio es una tabla de tramos indexada por longitud de prompt, que es para lo que sirve Tier[] en la función de coste, y por eso computeCost selecciona el tramo usando todo el prompt en vez de cada cubo por separado.

Los cinco cubos se corresponden con las dos fases del Capítulo 13, y una vez ves el mapeo las ratios de precio dejan de parecer arbitrarias.

Los input tokens son prefill. Todo el prompt pasa por el modelo en una sola pasada, procesado en paralelo: grandes multiplicaciones de matrices, limitadas por cómputo. El coste por token es bajo, y esta es la fase que fija el time to first token: un prompt de 4.947 tokens tiene 4.947 tokens de prefill que hacer antes de que aparezca la primera palabra.

Los output tokens son decode. Se producen uno a uno, cada uno con un forward pass completo que lee toda la KV cache, con la GPU más esperando a la memoria que calculando. Esta es la fase que fija los tokens per second, no puede paralelizarse dentro de una respuesta, y por eso el output cuesta unas seis veces el input en el modelo tasado aquí: $12.00 frente a $2.00 por millón de tokens.

De ahí se siguen directamente tres consecuencias. Una cache read sustituye trabajo de prefill, así que compra latencia y dinero a la vez: el mismo descuento aparece como una factura menor y una espera más corta hasta el primer token. Los reasoning tokens son decode que no ves, por eso un modelo de reasoning no streamea nada durante varios segundos y luego responde rápido: el Capítulo 12 advirtió de la consecuencia en la interfaz, y esta es la consecuencia en la factura. Y abortar un stream no detiene la generación: el Capítulo 14 construyó la cancelación y dejó el precio para este capítulo, y el precio es el recuento completo de output, porque los tokens se producen y facturan escuche alguien o no. Lo mismo ocurre con la respuesta que nadie conserva: regenerar una respuesta del turno 40 cinco veces cuesta $0.057990 por la única que queda en pantalla.

El tokenizer del Capítulo 7 era Python y se quedó allí. El budgeting ocurre en el servidor que construye la solicitud, así que tiene que ocurrir aquí, y hay exactamente tres niveles de precisión disponibles.

Nivel uno: contar localmente. js-tiktoken incluye las mismas tablas de fusiones BPE que el tiktoken de Python, así que da un recuento idéntico byte a byte para encodings de OpenAI, sin llamada de red:

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

Las dos constantes importan y son donde se desvían los recuentos locales. Tu texto no es lo que se tokeniza: la plantilla de chat del Capítulo 11 envuelve primero cada mensaje en marcadores de rol, y esos son tokens que pagas. Cuatro por mensaje y tres para el priming de la respuesta es la aproximación convencional para modelos de chat de OpenAI; en los ochenta y un mensajes de la conversación anterior suman 324 tokens, el 6,4 % de su longitud. Los recuentos aquí se contrastaron con el tiktoken de Python del Capítulo 7 en las ochenta y una cadenas y son idénticos.

Nivel dos: preguntar al proveedor. Anthropic expone /v1/messages/count_tokens y Google expone count_tokens, ambos aceptan la misma forma de solicitud que una llamada real y devuelven gratis un recuento de input tokens. Úsalos cuando no puedas contar localmente, y no puedes contar localmente en Anthropic, cuyo tokenizer no está publicado. La documentación de Anthropic es cuidadosa sobre lo que te da: el recuento «es una estimación», y «puede incluir tokens añadidos automáticamente por Anthropic para optimizaciones del sistema», por los que «no se te factura».¹⁰

Nivel tres: leer usage en la respuesta. Esa es la verdad, y llega después de gastar el dinero. Precisamente por eso existen los dos primeros niveles: para decidir si enviar la solicitud, no para facturarla.

Cuatro partidas que no aparecen como partidas.

El system prompt, pagado en cada llamada. El de arriba son 192 tokens con su sobrecarga de plantilla. En cuarenta llamadas son 7.680 tokens: el 5,6 % de toda la factura de esta conversación, por ocho líneas escritas una vez. También es el mejor candidato posible para cache, porque es estable y va primero.

Definiciones de herramientas. El nombre, la descripción y el esquema JSON de cada herramienta salen en cada solicitud, y los proveedores añaden andamiaje encima. Anthropic publica el número: activar herramientas añade de por sí un system prompt oculto de 496 tokens en Claude Sonnet 4.5 con tool_choice establecido en auto, o 588 con any o una herramienta con nombre.⁹ Eso es antes de tus propios esquemas. El Capítulo 18 construye el catálogo; el Capítulo 24 mide lo que consume.

Cada generación, incluidas las que descartas. Cinco regeneraciones cuestan cinco veces. El chat muestra una.

Pensamientos que no se te muestran. La facturación se basa en todos los thought tokens aunque solo se devuelva un resumen, y ninguna contabilidad tuya puede auditar ese número.

Una advertencia para cerrar, porque es la siguiente idea natural y la respuesta no es la obvia.

Una window de un millón de tokens no significa un millón de tokens utilizables. La precisión de retrieval se degrada con la posición: Liu et al. descubrieron que los modelos localizan información de forma fiable al principio y al final de un input largo, y con mucha menos fiabilidad en el medio.¹¹ Una window más grande compra la capacidad de enviar más, no la certeza de ser leído.

Ese fenómeno se mide una vez en este curso —la tasa de retrieval en nueve posiciones del mismo prompt de 853 tokens— y pertenece al Capítulo 24, donde cambia lo que hace un agent. Se cita aquí porque cambia lo que deberías comprar: el token más barato es el que no enviaste.

Ahora puedes predecir cuánto costará una llamada antes de hacerla, leer cuánto costó después y distinguir entre ambas cosas. Eso cubre todo lo relacionado con la solicitud salvo la parte que todavía no has tocado: los controles.

El Capítulo 17 es sampling: temperature, top-p, top-k, las penalizaciones y el determinismo que no tienes. Empieza desmontando el error más extendido del campo: que temperature es un dial de creatividad. No lo es: temperature divide los logits del Capítulo 4 antes de la softmax, y subirla no vuelve imaginativo al modelo, sube la probabilidad de tokens que el propio modelo puntuó como peores. A partir de ahí, por qué el greedy decoding produce texto mediblemente peor que el sampling, por qué top-k y top-p fallan con formas opuestas de distribución, y el experimento que cierra el capítulo: veinte forward passes idénticos a temperature 0 vuelven idénticos bit a bit cuando el modelo se ejecuta solo, y poner el mismo prompt en un batch junto a las solicitudes de otra persona mueve el 97 % de sus logits.

No coinciden todos. La razón empieza con el recuadro de floating point del Capítulo 2.

Todos los precios, umbrales y multiplicadores de este capítulo se leyeron de las propias páginas de los proveedores el 6 de septiembre de 2026 y se indican con esa fecha porque cambiarán. El método importa más que los números: los cubos, la regla del prefijo y la aritmética de tramos se han mantenido estables durante dos años mientras que cada cifra dentro de ellos se ha movido.

La clase 2 de Stanford CS336, Resource accounting, es el tratamiento académico más cercano de este material y la siguiente lectura adecuada: hace la misma aritmética en el lado del entrenamiento que este capítulo hace en el lado de la inferencia. Los recuentos de tokens aquí se produjeron con js-tiktoken 1.0.21 usando los encodings o200k_base y cl100k_base, sobre una conversación de cuarenta turnos y 5.090 tokens; la sobrecarga de plantilla por mensaje es la aproximación convencional de cuatro más tres y se indica allí donde se incluye. Las cifras de cache, tramos y truncación son las reglas de precios documentadas aplicadas a esos recuentos de tokens medidos, no observaciones de respuestas API en vivo: no se hizo ninguna llamada de pago para producir este capítulo, que es también la razón honesta por la que las afirmaciones de latencia son cualitativas y las de coste no.