Precios por contexto largo: hasta 6.7x sin avisar

El precio que aparece en la página de un modelo no coincide con el de la factura cuando el prompt crece demasiado. Enviamos solicitudes mediante un gran agregador multiproveedor justo por debajo y por encima de cada límite de longitud documentado para nueve modelos con precios escalonados. Cinco cobraron exactamente 2x el precio de la página al superar el primer límite. Los tres modelos de Alibaba subieron hasta 3x, 3x y 6.7x en el último tramo. Otro modelo servido por Azure cobró 1.25x la tarifa publicada del endpoint a ambos lados del límite y después duplicó el precio. Nada de esto aparece en la página. Los propios proveedores documentan el mecanismo: Google, OpenAI, xAI, Alibaba, ByteDance y MiniMax recalculan el precio de toda la solicitud, incluida la salida, al superar un límite de 32K, 128K, 200k, 256K, 272K o 512k tokens de entrada. Primero veremos las facturas, después las tablas de tramos que las explican y, por último, los ajustes que permiten mantener cada solicitud por debajo del límite.

TL;DR

• Nueve modelos con precios escalonados cobraron entre 1.8x y 6.7x al superar el límite del proveedor mediante un agregador cuyas páginas muestran un único precio. GPT-5.6 Luna vía Azure cobró 1.25x el precio publicado.
• qwen3.7-flash cobró $0.03, después $0.10 y finalmente $0.20 por millón de tokens de entrada en los límites de 32K y 256K. qwen3-coder-plus se quedó en 3x, aunque el proveedor publica 6x.
• Los proveedores recalculan el precio de toda la solicitud, incluida la salida, cuando la entrada supera un límite de entre 32K y 512k tokens.
• Limita la entrada, no la salida: Claude Code /autocompact, Codex model_context_window y los triggers de compactación de la API.

¿Los gateways cobran lo que indica su página?

No cuando el prompt es largo. Para averiguar cuánto cobran realmente hacen falta dos datos por intermediario: los metadatos de precios publicados por el gateway y el coste que registra para una solicitud a cada lado del límite.

Un gran agregador multiproveedor publica su catálogo con un array pricing.overrides: un precio base y reglas condicionales como min_prompt_tokens: 200000 con las tarifas superiores. En los modelos de DeepSeek y Tencent también incluye ventanas utc_start / utc_end para los precios en horas de menor demanda. En el catálogo que descargamos el 2026-09-01, 60 entradas contenían overrides. Entre ellas estaban los modelos Gemini Pro, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, los modelos Seed 2.0 y toda la familia GPT-5.6 en 272,000 tokens. Las páginas de los modelos solo muestran el precio base. El tramo superior está en los metadatos. Además, esos metadatos no siempre reproducen todos los tramos del proveedor: qwen3-coder-plus incluye reglas en 32,000 y 128,000, pero no el cuarto tramo que el proveedor sitúa en 256K.

Por eso enviamos solicitudes a ambos lados de cada límite documentado mediante ese agregador. Activamos el registro de uso, que devuelve en la respuesta el importe cobrado, y anotamos el endpoint que atendió cada solicitud. Un mismo id de modelo del agregador puede apuntar a varios hosts upstream, cada uno con su propio precio. El agregador los denomina endpoints. Hicimos dos ejecuciones por punto los días 2026-09-02 y 2026-09-03:

Capturamos las páginas el mismo día que las facturas. Ambas muestran un único precio principal, una tabla por endpoint y ningún tramo por longitud. Todos los cobros anteriores siguieron los metadatos exactamente. Los nueve modelos cambiaron de tramo en el primer límite del proveedor y aplicaron su mismo multiplicador. En los tres modelos de Alibaba, la factura recorrió una escala que la página no menciona. qwen3.7-flash pasó de $0.03 a $0.10 en 32K y a $0.20 en 256K, 6.7x el precio de la página, aunque esa página solo muestra $0.03. GPT-5.6 Luna también cambió de tramo y añadió otra diferencia: todas las ejecuciones servidas por Azure se cobraron a 1.25x el precio publicado del endpoint de Azure, tanto por debajo como por encima del límite ($0.275 frente a $0.22, y $0.50 y $0.55 frente a $0.40 y $0.44). Ese recargo no aparece ni en la página ni en los metadatos del endpoint.

La escala también puede terminar antes que la del proveedor. En qwen3-coder-plus, el precio subió a 1.8x en 32K y a 3x en 128K, pero se mantuvo en $1.95 por millón hasta 276k tokens. La tarifa de Alibaba pasa allí a $6 para la entrada y $60 para la salida, seis y doce veces el precio base. Los metadatos del agregador no incluyen ninguna regla en 256K, así que el cobro no cambió. Desde fuera no se puede saber si el agregador absorbe la diferencia o compra el servicio mediante otro contrato. Lo que sí puede comprobarse es que la factura sigue los metadatos, mientras que los metadatos y la página son documentos distintos.

La falta de transparencia no está entre los metadatos y la factura, sino entre la página y ambos. El precio principal de la página corresponde al endpoint más barato de la tabla inferior, no necesariamente al endpoint que atenderá la solicitud. Ninguno de esos precios incluye la condición de longitud. Una ficha con un solo precio no informa del tramo aplicable, del endpoint que servirá la siguiente solicitud ni de si tu cuenta puede acceder al endpoint cuyo precio estás consultando.

La regla práctica es sencilla. Consulta el precio legible por máquina del modelo que usas, desglosado por endpoint, y busca condiciones de longitud. Después, envía una solicitud a cada lado del límite con el registro de uso activado y compara el coste devuelto. Si el gateway cambia el precio donde su página no lo indica, está trasladando una regla del proveedor sin mostrarla. Si mantiene el precio donde el proveedor lo aumenta, está sirviendo el modelo desde un host con otras tarifas o absorbiendo la diferencia. Solo la primera opción es estable.

¿Dónde están los límites y cómo se aplica cada tramo?

Seis proveedores publican límites de longitud. En todos los modelos que documentan esta regla, la tarifa superior se aplica a todos los tokens de la solicitud, incluida la salida. En la mayoría de los primeros límites, el precio sube a 2x, pero algunas escalas llegan más lejos: 3x en el único límite de qwen3.7-plus, 6.7x para la entrada en el tercer tramo de qwen3.7-flash, y 6x para la entrada y 12x para la salida en el cuarto tramo de qwen3-coder-plus. Los precios son por millón de tokens y se obtuvieron de las páginas de precios de los proveedores el 2026-09-01.

Conviene reproducir dos detalles de los límites en el código de billing. Las dos páginas de Google difieren en un token: la nota de Vertex dice “igual o superior a 200K”, mientras que la tabla de precios de la API de Gemini dice “prompts > 200k tokens”. Alibaba también define K de forma precisa: 128K equivale a 128,000 tokens y 256K a 256,000, no a potencias de dos.

El tramo se elige únicamente según la longitud de la entrada, pero se aplica a toda la solicitud, incluidos todos los tokens de salida. Por tanto, el coste marginal del token que cruza el límite incluye todo el recargo aplicado a los tokens anteriores. En Gemini 2.5 Pro, un prompt de 199,999 tokens cuesta $0.25 de entrada. Con 200,001 tokens cuesta $0.50, y una respuesta de 4,000 tokens pasa de $0.04 a $0.06. Un token adicional añade $0.27.

En qwen3.7-plus, el salto es de 3x: la tarifa oficial de un prompt de 255,029 tokens es $0.102, mientras que uno de 257,332 tokens cuesta $0.309. En qwen3-coder-plus, el mismo mecanismo se acumula a lo largo de cuatro tramos. Un prompt de 260k tokens paga seis veces la tarifa por token de uno de 30k, y su salida paga doce veces más.

La regla también aparece en facturas reales, no solo en la tabla del proveedor. En qwen3.5-plus, cuyas tarifas oficiales pasan de $0.40 a $0.50 por millón de tokens de entrada en 256K, el coste de nuestra factura por token de entrada difirió exactamente en 1.25x entre diez ejecuciones por debajo del límite (243k tokens) y 24 ejecuciones por encima (entre 256k y 321k), sin cambios en el precio de salida. La solicitud de 259k no pagó 1.25x solo por sus últimos 3k tokens. Pagó 1.25x por todos.

En un agente que acumula historial, el cruce se produce en mitad de la sesión y sin aviso. El turno que supera el límite paga el recargo por todos los turnos anteriores que incluya. Los turnos posteriores siguen pagándolo hasta que se reduzca el contexto.

¿La capacidad cambia en el mismo límite?

No. Lo medimos porque es fácil confundir el tramo de precio con un límite de capacidad, pero no lo es. En dos modelos Qwen con un límite de 256K, insertamos una aguja con salt, un dato de una línea que incluía un código aleatorio distinto en cada ejecución, a cinco profundidades. Con thinking desactivado, ambos modelos la recuperaron 30 de 30 veces en 243k, 269k y 320k tokens. La latencia creció de forma gradual con la longitud, sin ningún salto: medianas de 15.2 s, 17.0 s y 20.5 s en qwen3.7-plus. Una tarea más difícil, contar K apariciones poco frecuentes distribuidas por todo el registro, sí empeoró al aumentar la longitud. En qwen3.7-plus, la proporción encontrada bajó del 74% en 128k al 60% en 192k, al 58% en 243k y al 45% en 320k. La degradación comienza mucho antes del límite de precio, y los resultados a ambos lados siguen la misma pendiente.

La documentación de Anthropic da nombre a este efecto gradual: a medida que aumenta el número de tokens, la precisión y el recall empeoran, un fenómeno conocido como context rot. El efecto es real y continuo. No depende de dónde esté el tramo de precio.

¿Cómo mantener una solicitud por debajo del límite?

Limita la entrada, no la salida. El tramo depende de la longitud de entrada de la solicitud, así que max_tokens, que limita la salida, no sirve para evitarlo. Hay que usar los ajustes que limitan lo que envía el cliente. Existen en cuatro capas.

Estos son los ajustes que limitan el prompt en cada capa. “¿Evita un tramo?” identifica los que aceptan un número absoluto de tokens y pueden configurarse justo por debajo de un límite de precio. Los ajustes relativos a la ventana solo mantienen la solicitud dentro de la ventana de contexto del modelo, que es un límite distinto.

La tabla deja dos conclusiones. Si un agente de código usa un modelo con precios escalonados, la ventana de compactación es el ajuste que sustituye el salto por un resumen. Debe configurarse con un número absoluto de tokens justo por debajo del límite, no como fracción de una ventana de 1M. Además, los dos ajustes de seguridad más habituales, Responses truncation: "auto" y middle-out del agregador, solo protegen la ventana. Se activan al alcanzar la ventana del modelo, 1M en los modelos escalonados Gemini y GPT-5.6, no en los 200,000 o 272,000 tokens donde cambia el precio. Evitan que la solicitud falle, pero no que cruce el límite de precio.

No confíes en el cache para evitar el tramo superior. El prompt caching reduce la factura, pero no evita el cambio de tramo en los modelos de Google, donde las lecturas de cache se cobran según el mismo tramo de longitud. Un prefijo de 150k en cache más 60k de contexto nuevo forman un prompt de 210k y se cobran como uno solo. La capacidad aprovisionada evita por completo este problema, ya que las provisioned throughput units (PTU) se cobran por hora, independientemente de los tokens. Si compensa superar el límite, hazlo de forma deliberada. Las mediciones anteriores muestran que el modelo no empeora justo en ese punto. La decisión depende únicamente de si el contexto marginal justifica aplicar un multiplicador de 2x, 3x o, en los tramos superiores, 6.7x a toda la solicitud.

Cómo lo gestiona Synthorai

Un tramo por longitud es una condición de tarifa, y el gateway lo trata como tal. La ficha de precios de un modelo puede contener una lista de tramos definidos por límites de tokens de entrada. Cada solicitud se factura según el tramo seleccionado por la longitud de su propio prompt, aplicado a todos sus tokens, igual que hace el proveedor. Este es el mecanismo que se activó en la factura de qwen3.5-plus anterior. El registro de uso conserva el número de tokens del prompt y la versión del precio junto al coste calculado. Así, una factura puede desglosarse hasta indicar que una solicitud concreta cruzó el límite. El tramo usado para cobrar una solicitud puede consultarse en el registro de uso, no solo en una tabla de precios.

Preguntas frecuentes

¿La tarifa superior de contexto largo se cobra solo por los tokens que superan el umbral?

No. Todos los proveedores que documentan la regla recalculan el precio de toda la solicitud: Google indica que “todos los tokens (de entrada y salida) se cobran con las tarifas de contexto largo”; OpenAI, que se aplica “a toda la solicitud”; xAI, “a todos los tokens de la solicitud”; y Alibaba, que “todos los tokens de la solicitud se cobran al precio unitario del tramo correspondiente”. Un prompt que supera el límite por un solo token paga el recargo por todos los tokens anteriores.

¿Los gateways de API trasladan los tramos de precios por contexto largo?

Sí, según nuestras mediciones. Mediante un gran agregador, nueve modelos con precios escalonados cobraron la tarifa superior del proveedor al superar su límite, aunque sus páginas muestran un único precio. El tramo está en los metadatos de precios del gateway, no en la página. Los metadatos también pueden omitir un tramo del proveedor, como ocurrió con qwen3-coder-plus por encima de 256K.

¿max_tokens mantiene una solicitud por debajo de un tramo de precio?

No. max_tokens limita la salida, mientras que el tramo se determina por la longitud de entrada. Sirven los ajustes que limitan el prompt: una ventana de compactación o un límite de tokens en el agente, como Claude Code /autocompact o Codex model_context_window, un trigger de compactación en la API o el truncado en el cliente antes de enviar la solicitud.

¿La calidad del modelo cae en el límite de precio?

No en nuestras mediciones. En dos modelos Qwen con precios escalonados, el recall de la aguja fue perfecto a ambos lados del límite de 256K. Una tarea de conteo empeoró de forma gradual al aumentar la longitud, sin ningún salto en el límite. El tramo es una regla comercial. La pérdida de capacidad con contextos más largos es real, pero continua.

Precios y reglas tomados de las páginas de precios de los proveedores consultadas el 2026-09-01; ajustes de agentes y API tomados de la documentación enlazada el 2026-09-02; mediciones de facturas realizadas entre el 2026-09-01 y el 2026-09-03, con thinking desactivado, prompts con salt y dos ejecuciones por punto del agregador. Los precios cambian; consulta la fuente enlazada antes de incorporar un límite al código de billing.

Relacionado: guía de unidades de billing (la capa de modificadores en la que profundiza este artículo), anatomía del uso de tokens, cómo funciona el prompt caching, medición de mínimos de cache.

← Volver al blog