Guía de costes de GPT-5.6: 90% de descuento en prompt caching y reasoning effort

GPT-5.6 mueve las dos palancas de coste a la vez: el input cacheado baja al 10% de la tarifa de input (en la 5.x era el 50%), y como el reasoning viene activado por defecto, no enviar reasoning_effort facturó 1,5x más que fijarlo en none en nuestra matriz de 50 llamadas, con respuestas idénticas. En el input ahora puedes fijar explícitamente hasta cuatro cache breakpoints; en el output, el knob de effort decide cuánto pagas por pensar. Medimos ambas palancas a través del gateway con los modelos disponibles desde el primer día: Sol ($5/$30 por 1M de tokens in/out), Terra ($2.50/$15) y Luna ($1/$6), y confirmamos cada tarifa contra el medidor usage.cost en vivo.

TL;DR

• El input cacheado se factura al 10% de la tarifa de input; medimos $0.10/$0.25/$0.50 por 1M según el tier. En la 5.x era el 50%.
• Los breakpoints dan reutilización parcial: cambiar el bloque tras un marcador refacturó solo 1.210 de 2.431 tokens.
• Los prefijos por debajo de 1.024 tokens nunca cachean y las repeticiones pueden fallar en silencio; presupuesta tasas de acierto por debajo del 100%.
• Las escrituras de caché se facturan a 1,25x sobre los tokens escritos; una escritura que nunca se lee cuesta más que no cachear.
• Omitir reasoning_effort facturó 1,5x más que none en una matriz de 4 tareas, con respuestas idénticas; fíjalo explícitamente.

Medido el 2026-07-10 a través del gateway de Synthorai (chat completions compatible con OpenAI), un día después de que OpenAI anunciara la familia. Los tres modelos están disponibles; los nuevos parámetros de caching pasan sin cambios.

Tres tiers, una generación

El esquema de nombres es nuevo: el número es la generación, y Sol, Terra y Luna son tiers de capacidad que reemplazan los sufijos pro/mini/nano. Los tres comparten una ventana de contexto de 1M de tokens y un output máximo de 128K. Cada tarifa de abajo cuadra exactamente contra el usage.cost medido sobre recuentos de tokens conocidos, incluida la columna del cacheado:

Sol es el buque insignia y el sucesor a mismo precio de gpt-5.5: la tarifa es idéntica, $5/$30. Terra y Luna son los tiers reducidos de la misma generación, a la mitad y a un quinto del precio de Sol, ocupando los huecos que antes tenían los sufijos mini y nano. Para el conteo de tokens los tres son un mismo modelo: todos devolvieron recuentos idénticos en cada muestra que enviamos.

Cómo funciona el caching en 5.6, según la documentación

El caching de GPT era antes un único comportamiento: la API detectaba por su cuenta prefijos repetidos de 1.024+ tokens y facturaba la parte cacheada a mitad de precio. Por eso nuestra comparativa de proveedores clasificó la columna de GPT como “totalmente automático”. La guía de caching de 5.6 reemplaza eso con un diseño de dos modos:

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

Las reglas que importan, resumidas de la guía:

• Un breakpoint marca el final de un prefijo cacheado, cubriendo ese bloque y todo lo anterior. El modo implicit (el predeterminado) sigue colocando automáticamente un breakpoint en el último mensaje; el modo explicit cachea solo lo que marcas.
• Cuatro escrituras de caché por request, y el auto-breakpoint del modo implícito consume una de ellas, así que los marcadores explícitos disponen de tres slots en el modo por defecto y cuatro en el modo explícito. Los breakpoints de turnos anteriores de la conversación quedan en solo lectura en los requests posteriores.
• El mínimo de 1.024 tokens se mantiene: un prefijo marcado por debajo de ese umbral no se cachea.
• ttl: "30m" es un tiempo de vida mínimo garantizado, no un tope (“al menos 30 minutos… puede retenerlo más tiempo”). Reemplaza a prompt_cache_retention, que queda deprecado en 5.6, y con ello desaparece también la antigua opción de retención extendida 24h.
• prompt_cache_key es la forma de conseguir coincidencias fiables: la guía recomienda una clave estable por tenant o sesión para enrutar las repeticiones al mismo caché, con un límite blando de unos 15 requests por minuto por clave. Los cachés tienen alcance a tu organización.
• Las escrituras de caché se facturan a 1,25x la tarifa de entrada en 5.6+, reportadas en el nuevo campo usage.prompt_tokens_details.cache_write_tokens. En 5.x y anteriores las escrituras eran gratuitas.

GPT-5.5 y versiones anteriores rechazan los nuevos parámetros con un 400 limpio (prompt_cache_options is not supported on this model), así que aplica un gate por versión en cualquier despliegue.

Si el diseño te suena, es normal: marcadores en bloques de contenido, cuatro breakpoints, un sobrecoste por escritura y un historial deslizante en solo lectura son la forma que ha tenido siempre el cache_control de Claude. La diferencia está en el TTL: el mínimo garantizado de 30 minutos de OpenAI es 6 veces los 5 minutos por defecto de Claude.

Lo que dice el medidor

Los docs son afirmaciones; esto es lo que devolvió el medidor del gateway, sonda por sonda. Los registros crudos completos están en el log de la corrida; cada costo de abajo cuadra al dígito contra las tarifas de cada tier.

Tres de esas filas merecen explicación.

La reutilización parcial es real, y es la razón para adoptar breakpoints. Con un bloque A estable y una cola B cambiada, el medidor solo volvió a facturar la cola: 1,212 tokens releídos a la tarifa de caché, 1,210 escritos para el nuevo B al premium de escritura, de un prompt de 2,431 tokens, y el total cuadra al dígito contra la tarifa. Ese es el comportamiento de prefijo por capas (system prompt, luego tools, luego documentos, cada uno marcado) alrededor del cual los usuarios de Claude estructuran sus prompts, y que el modo automático de GPT nunca pudo garantizar. Una nota al pie: en repeticiones completas la longitud coincidente a veces baja por debajo de la marca (1,897 de una escritura de 2,422 tokens en una sonda), así que presupuesta con la tarifa de descuento, no con conteos de coincidencia exacta.

El suelo y los fallos silenciosos son las trampas operativas. Un bloque marcado de 621 tokens no almacenó nada en caché, dos veces, sin error y sin más pista de uso que los ceros; si tu “prefijo estable” es un system prompt corto, estás pagando el precio completo y nada te lo indica. Y un fallo puede llegar sin una escritura, a precio completo, igualmente en silencio. La tasa de aciertos es una distribución, no una promesa, sea cual sea el camino que tomen tus solicitudes: lee cached_tokens en producción y configura alertas al respecto, como hace nuestra auditoría de caché de cinco minutos.

El premium de escritura es real, y cambia el punto de equilibrio. Los tokens escritos se facturan a exactamente 1.25x la tarifa de input en los tres tiers (las escrituras de Luna miden $1.25 por millón, Terra $3.125, Sol $6.25), cuadrando al dígito en cada sonda de nuestra corrida final. Ese premium solo se amortiza cuando el prefijo se vuelve a leer: una escritura que nunca recibe un acierto cuesta un 25% más que no cachear en absoluto, la misma trampa que medimos con el premium de escritura de Claude en el post de LangChain. Marca los prefijos que sabes que se van a repetir, no todo lo que parece estable.

El límite de 30 minutos se mantuvo hasta donde lo probamos. Una relectura con clave 15 minutos después de la escritura volvió completamente en caché (1,313 de 1,313 tokens, reconciliándose a la tasa del 10%), muy por encima del antiguo horizonte en memoria de 5 a 10 minutos, y una segunda prueba con clave con el mismo intervalo repitió el resultado. No probamos los 30 minutos completos.

La misma carga en GPT-5.5, a modo de contraste

La comparación justa es a igualdad de precio: Sol usa exactamente la misma tarifa que gpt-5.5 ($5/$30), así que es el sucesor equivalente, con Terra y Luna como los niveles reducidos por debajo. Mismo precio de lista, condiciones de caché muy distintas:

Al mismo precio de lista, las condiciones de caché son la mejora. Un prefijo de 3.000 tokens cuesta $0.0075 por llamada en 5.5 cuando su caché automática decide acertar, y $0.0015 en Sol caliente, 5 veces menos en la porción cacheada. El cambio más profundo es el control y la visibilidad: los aciertos de 5.5 dependen de una detección opaca de prefijos que no puedes ni activar ni depurar, mientras que 5.6 te permite marcar exactamente qué debe cachearse, enrutar repeticiones con una prompt_cache_key, y observar cada escritura aterrizar en usage. Un fallo ahora aparece como un cero en un campo que tú creaste, no como silencio. La ruta de reducción escalonada se apila encima: si 5.5 estaba sobreatendiendo la carga de trabajo, Terra reduce a la mitad toda la lista de tarifas y Luna la divide entre cinco, y el mismo prefijo caliente baja a $0.00075 y $0.0003. Lo único que 5.5 conserva es la retención opcional de 24 horas; si tu tráfico es un lote diario contra un prefijo gigante, esa disyuntiva corre en el sentido contrario. Y ten en cuenta que la segunda palanca corta en la otra dirección en la migración: 5.6 razona por defecto, así que una carga de trabajo de 5.5 trasladada sin fijar reasoning_effort adquiere nuevo gasto de salida con la misma lista de tarifas.

La segunda palanca: el esfuerzo de razonamiento

El caché controla lo que pagas por la entrada; reasoning_effort controla el lado de la salida, porque los tokens de razonamiento se facturan a la tarifa de salida y, a diferencia del prefijo, nunca se pueden cachear. GPT-5.6 acepta desde none hasta xhigh en todos los tiers. El post de lanzamiento también presenta un esfuerzo max para Sol; a través de chat completions no existe (400: 'reasoning_effort' does not support 'max' with this model, tanto en Sol como en Terra), así que xhigh es el techo práctico en la ruta de la API que usan gateways y SDKs.

Corrimos una matriz de 50 llamadas: cuatro tipos de tarea (clasificar una reseña, extraer un campo de una línea de log, un problema matemático de varios pasos y una tarea pequeña de generación de código) en los seis ajustes, de none a xhigh más el parámetro omitido, sobre Terra y Luna con una verificación puntual en Sol. Las 50 respuestas fueron correctas en todos los ajustes. Lo que varió fue la factura. Son llamadas de salida corta (decenas de tokens visibles), así que unas pocas docenas de tokens de razonamiento a la tarifa de salida dominan el total; la columna de ratio compara el costo de la llamada completa:

Tres hallazgos. Primero, 5.6 es adaptativo por sí solo: en los dos tipos triviales ningún ajuste gastó un solo token de razonamiento, así que ahí la perilla es gratis. Segundo, en los tipos que parecen merecer reflexión (math, code), el default razona aunque no aporte nada: omitir el parámetro costó de 2.5x a 3.5x el precio de none en math y code de Luna y en math de Terra (la corrida de code de Terra resultó no gastar nada en default) para las mismas respuestas correctas, y 1.5x más sumado sobre toda la grilla de Terra y Luna. Tercero, los ajustes intermedios (no mostrados en la tabla) son ruido, no un dial: la corrida de math de Terra gastó 19 tokens de razonamiento en low, cero en medium, 21 en high y cero de nuevo en xhigh, y la corrida de code de Luna gastó 101 en xhigh contra 41 en high. Los nombres son intenciones, no presupuestos, el mismo comportamiento que medimos en GLM 5.2.

Envía reasoning_effort explícito en cada llamada y ponlo por defecto en none para clasificación, extracción, ruteo y transformaciones cortas. Escala un call site específico solo cuando tus evals muestren que el ajuste más alto cambia los resultados, no porque la tarea se sienta difícil. Nuestros cuatro tipos son cargas de API de salida corta; el trabajo genuinamente difícil de varios pasos quizá justifique su gasto de razonamiento, pero deja que lo digan las mediciones.

Las dos palancas se combinan. Una vez que el prefijo está caliente, el lado de entrada de una llamada a Luna cuesta una décima parte del precio de lista, y el default de razonamiento pasa a ser el mayor renglón restante en tareas cortas: la llamada de math de Luna costó $0.00007 en total en none y $0.00025 con el parámetro omitido: solo el default de razonamiento agregó $0.00018, más del doble de toda la llamada gestionada. Cachea sin fijar el esfuerzo y el ahorro se escapa por el otro lado.

Qué recomendar según la carga

La decisión ya tiene una estructura clara, así que esto es lo que le decimos a los clientes del gateway:

Independiente de la forma: envía un prompt_cache_key estable por inquilino o sesión (la documentación convierte la clave en la base de una coincidencia fiable), mantén cada capa marcada por encima del límite de 1,024 tokens, y monitorea cached_tokens porque existen fallos silenciosos. Recuerda que las cachés son por modelo: una prueba A/B entre niveles se recalienta desde cero en cada lado. Y ajusta la otra palanca en el mismo commit: fija reasoning_effort según la matriz anterior, none salvo que una evaluación indique lo contrario.

Sobre la elección de tier, el descuento del 90% cambia la aritmética más que el propio tier. Una carga que reproduce un prefijo de 3.000 tokens paga unos $0,30 por cada mil llamadas por ese prefijo en tráfico Luna caliente, y $1,50 en Sol caliente; la diferencia entre tiers sobre la parte cacheada es menor que la diferencia sobre los tokens de salida, así que elige el tier por la calidad de salida y el precio, y deja que el caché aplane el lado de la entrada. Viniendo de gpt-5.5, Sol es el upgrade directo con el mismo rate card, lecturas de caché 5x más baratas y control sobre cuándo ocurren; baja a Terra o Luna donde tus evals digan que el tier menor aguanta, y el rate card se divide entre dos o entre cinco encima de eso.

El tokenizer no cambió

Nuestras 24 muestras (un pasaje narrativo en nueve idiomas, versiones técnica y de noticias en seis de ellos, una función de Python y un tool-call en JSON) cuentan idéntico en GPT-5.5, Sol, Terra y Luna en cada comparación que se completó. Los presupuestos de tokens y las estimaciones del suelo de caché calibrados sobre 5.5 siguen valiendo sin cambios; el comportamiento entre idiomas está en nuestro post sobre el tokenizer por idioma y aplica a 5.6 tal cual.

En resumen

• El descuento del caché pasando del 50% al 90%, con un TTL garantizado de 30 minutos, es el verdadero recorte de precio de este release; los precios por tier son el titular, pero los términos de caché mueven facturas reales mucho más.
• Adopta breakpoints explícitos para prompts por capas: el reuso parcial está medido, no es teórico, y el modelo mental se transfiere de Claude uno a uno.
• Respeta el suelo de 1.024 tokens, envía un prompt_cache_key y monitorea cached_tokens; existen tanto los fallos silenciosos como el no-cacheado-en-absoluto silencioso.
• Envía reasoning_effort de forma explícita, con default none: el default sin gestionar facturó 1,5x más en toda nuestra matriz, hasta 3,5x en tareas individuales, para respuestas idénticas.
• xhigh es el techo alcanzable (max 400s a través de chat completions); sin recalibrar el tokenizer respecto a 5.5.

Preguntas frecuentes

¿GPT-5.6 admite prompt caching explícito como Claude? Sí. Se usa prompt_cache_options: {"mode": "explicit"} junto con marcadores prompt_cache_breakpoint en los bloques de contenido, hasta cuatro escrituras por petición (tres en modo implícito, donde el breakpoint automático ocupa un espacio). Medido a través de un gateway compatible con OpenAI, un prefijo marcado de 3.012 tokens se escribió en la primera llamada y se leyó completo a la tarifa cacheada en la segunda.

¿Cuánto cuesta el input cacheado en GPT-5.6? El 10% de la tarifa de input, medido en los tres tiers: $0,10 por millón en Luna, $0,25 en Terra y $0,50 en Sol. GPT-5.x facturaba los tokens cacheados al 50% del input, así que la tarifa por token cacheado es 5 veces menor en 5.6.

¿El caching de GPT-5.6 es mejor que el de GPT-5.5? En profundidad del descuento y control, sí: tarifa cacheada del 10% frente al 50%, cuatro breakpoints explícitos frente a una detección solo automática que no puedes disparar ni depurar, y un mínimo garantizado de 30 minutos con clave frente a los 5-10 minutos de mejor esfuerzo. La única ventaja que le queda a 5.5 es el tier opcional de retención de 24 horas, que 5.6 elimina.

¿Cuánto tiempo vive la caché de GPT-5.6? La documentación garantiza al menos 30 minutos (ttl: "30m" es el único valor aceptado), posiblemente más; la opción reemplaza al obsoleto prompt_cache_retention, incluido el antiguo nivel extendido de 24 horas. En nuestras pruebas, las relecturas con clave 15 minutos después de la escritura acertaron por completo; no probamos los 30 completos.

¿Necesito prompt_cache_key? Envíalo: la documentación convierte una clave estable por inquilino o sesión en la base de una coincidencia fiable en 5.6, con un límite blando de alrededor de 15 solicitudes por minuto por clave. No cuesta nada incluirlo, y combinarlo con la monitorización de cached_tokens es como verificas que el descuento realmente se está aplicando.

¿Cuánto cambia reasoning_effort el coste de GPT-5.6? En nuestra matriz de 50 llamadas (cuatro tipos de tarea, seis ajustes, Terra y Luna), todos los ajustes dieron respuestas correctas, y omitir el parámetro facturó 1,5 veces más que none en conjunto, hasta 3,5 veces más en la tarea aritmética. En tipos triviales (clasificación, extracción) ningún ajuste gastó tokens de reasoning. Fija none y escala solo cuando lo justifiquen las evals.

¿Está disponible el máximo reasoning effort en GPT-5.6 Sol? No a través de chat completions. Las peticiones con reasoning_effort: "max" devuelven un 400 que lista desde none hasta xhigh, tanto en Sol como en Terra.

¿Qué tier de GPT-5.6 debería usar una carga de trabajo de API? Sol es el sucesor de gpt-5.5 con paridad de precio (mismo tarifario de $5/$30, lecturas cacheadas 5 veces más baratas); Terra y Luna son los tiers reducidos a la mitad y a un quinto de eso. Una vez que tu prefijo es estable y tiene clave, el descuento de caché del 90% aplana el lado del input, así que baja de tier tanto como te lo permitan tus evals de calidad de output y deja que el tier fije el precio de salida.

← Volver al blog