Precios por clase de token, explicados

Guías · 2026-09-06

Por qué la entrada, las lecturas de caché, las escrituras y la salida se cobran por separado, cuánto cobra cada modelo por clase y una petición real resuelta.

Cada petición que envías aquí se cobra en créditos, y el número de créditos no es el número de tokens. Cuatro clases de token se miden por separado — entrada sin caché, lectura de caché, escritura de caché y salida — porque servirlas cuesta cantidades distintas, y una tarifa única mezclada significaría cobrar la carga de trabajo barata de un cliente al precio de la cara de otro. Esta es la aritmética por clase al completo, sobre nuestras propias cifras publicadas, con una petición real desmontada al final.

Por qué las clases se cobran por separado

Un token que el modelo tiene que leer por primera vez, un token que relee de un prefijo guardado en caché, un token que escribe en esa caché y un token que genera son cuatro cantidades de trabajo distintas. Generar es lo caro: un token de salida se produce paso a paso, y todos los modelos lo cobran muy por encima de su propia entrada. La lectura de caché es lo barato, porque el trabajo que hay detrás ya se hizo y ya se pagó en una petición anterior. Las escrituras de caché no nos cuestan nada aguas arriba, y aquí se publican a la tarifa de entrada de cada modelo, que es la mitad del margen que se puede enseñar y no la que se esconde.

Un precio plano por token es más fácil de anunciar y peor de comprar. Cobra de más a la carga de trabajo que aprovecha la caché, cobra de menos a la que genera respuestas largas y — la parte que más importa — deja a cualquiera sin nada contra lo que contrastar una factura. Esa última parte es la prueba a la que sometemos nuestro propio medidor: cada cargo tiene que poder reproducirse a partir de los precios guardados en la línea del libro que tiene al lado, y una tarifa mezclada a partir de dos precios lo hace imposible por construcción — la mezcla no aparece en ninguna columna, así que no queda nada en el registro que se pueda recalcular. Por eso aquí no se mezcla nada. Cada clase se mide a la tarifa publicada para ella, y la tarifa publicada es la tarifa cobrada.

Cuánto cuesta un token, por clase

Créditos por token, por modelo y por clase, tomados del mismo catálogo del que sale cualquier otro precio de este sitio:

Un token de entrada de sol es un crédito. Ese es el ancla contra la que está escrita toda la tabla, y cada casilla restante es su propia proporción respecto a él: lee una fila de izquierda a derecha y tienes los cuatro precios de un modelo; lee la columna de entrada de arriba abajo y tienes lo que cuesta la capacidad. Nada de la tabla es una cifra de marketing redondeada — son los multiplicadores que aplica el medidor, y tu portal detalla cada petición contra ellos.

La lectura de caché es una décima parte

Un token releído de un prefijo en caché se cobra a una décima parte de la tarifa de entrada de su propio modelo, que es lo que hace que la columna de lectura de caché de arriba sea la columna de entrada dividida entre diez, modelo a modelo. El descuento es una línea propia en cada petición del portal, y no una media suavizada a lo largo de tu mes: un agente que reenvía el mismo system prompt largo en cada turno tiene que poder ver llegar el ahorro, petición a petición, y comprobarlo.

Una petición real, resuelta

La cuenta de abajo es una petición sobre astra: 303 tokens de prompt sin nada en caché y 14 tokens de respuesta. Las tarifas que salen en ella son las de astra el día en que se escribió esto; la tabla de arriba es la viva, y si alguna vez discrepan, manda la tabla.

POST /v1/chat/completions          model: astra

  clase    tokens        tarifa      créditos
  input       303  x       2.5   =      757.5
  output       14  x      12.5   =      175.0
                                      -------
  cobrado                               932.5  ->  933

Dos cosas sobre esa última línea. El total se redondea hacia arriba una sola vez, al final, y no clase por clase: redondear cada clase sería redondear cuatro veces y cobrarte la aritmética. Y la suma se calcula con aritmética entera exacta sobre los precios guardados en la propia línea del libro, así que no hay desviación de coma flotante entre lo que cobró el medidor y lo que la línea dice que cobró — la línea se puede recalcular a mano, que es lo que la hace auditable.

Lo que hace la reserva antes de la factura

Antes de que una petición salga hacia el proveedor, el medidor reserva una estimación contra tu cuota y anota los precios con los que va a liquidar. Eso es lo que impide que una ráfaga de peticiones simultáneas gaste dos veces los mismos últimos créditos: el saldo de tu portal se mueve cuando la petición empieza, no cuando termina, así que el número que estás mirando es un número que ninguna otra petición puede gastar también.

Cuando llega la respuesta, la reserva se liquida con el uso que el proveedor informó realmente, a los precios anotados en el momento de reservarla — de modo que un cambio de tarifa a mitad de petición no puede volver a tarificar una petición que ya está en marcha. Una liquidación nunca es mayor que la reserva que liquida: una petición cuyo coste real acabe por encima de lo reservado se queda sin liquidar y se marca para conciliación, en vez de seguir consumiendo tu cuota en silencio. La parte no usada de cada reserva vuelve de inmediato.

Dónde mirar a continuación

Los mismos pesos, en contexto corto y en contexto largo, y para qué sirve cada modelo: Modelos. Cuánto cuesta un plan y qué es un crédito: Planes y precios. La base URL y una petición que puedes copiar: Inicio rápido.

Traducción automática, pendiente de revisión por un hablante nativo. La versión en inglés es la de referencia.