Costes de GPT-5.6: 90% menos con prompt caching y reasoning effort

GPT-5.6 modifica a la vez las dos palancas de coste: el input cacheado baja al 10% de la tarifa de input, frente al descuento del 50% de 5.x. Además, el razonamiento viene activado por defecto. En nuestra matriz de 50 llamadas, no enviar reasoning_effort costó 1.5x más que fijarlo en none, con respuestas idénticas. En el input ahora se pueden definir explícitamente hasta cuatro breakpoints de caché; en el output, el nivel de esfuerzo determina cuánto razonamiento se paga. Medimos ambas palancas a través del gateway con los modelos disponibles desde el primer día: Sol ($5/$30 por 1M de tokens de entrada/salida), Terra ($2.50/$15) y Luna ($1/$6). Contrastamos todas las tarifas con el medidor usage.cost en producción.

TL;DR

• El input cacheado se factura al 10% de la tarifa de input: medimos $0.10/$0.25/$0.50 por 1M en los distintos tiers. En 5.x el descuento era del 50%.
• Los breakpoints permiten reutilizar parcialmente el prompt: al cambiar el bloque posterior a un marcador, solo se volvieron a facturar 1,210 de 2,431 tokens.
• Los prefijos de menos de 1,024 tokens nunca se cachean y las repeticiones pueden fallar sin avisar; hay que presupuestar un hit rate inferior al 100%.
• Las escrituras en caché se facturan a 1.25x sobre los tokens escritos. Escribir algo que nunca se lee cuesta más que no cachearlo.
• En una matriz de 4 tareas, omitir reasoning_effort costó 1.5x más que none, con respuestas idénticas. Conviene fijarlo explícitamente.

Mediciones realizadas el 2026-07-10 a través del gateway de Synthorai, usando chat completions compatibles con OpenAI, un día después de que OpenAI anunciara la familia. Los tres modelos están disponibles y los nuevos parámetros de caché llegan al proveedor sin cambios.

Tres tiers, una generación

El esquema de nombres es nuevo: el número identifica la generación, mientras que Sol, Terra y Luna representan tiers de capacidad que sustituyen a los sufijos pro/mini/nano. Los tres comparten una ventana de contexto de 1M de tokens y un output máximo de 128K. Todas las tarifas de la tabla cuadran exactamente con el usage.cost medido para cantidades conocidas de tokens, incluida la columna de input cacheado:

Sol es el modelo principal y sucede a gpt-5.5 manteniendo el mismo precio: la tarifa sigue siendo $5/$30. Terra y Luna son los tiers reducidos de la misma generación. Cuestan la mitad y una quinta parte que Sol, respectivamente, y ocupan el lugar de los antiguos sufijos mini y nano. A efectos del conteo de tokens, los tres se comportan como un único modelo: devolvieron los mismos conteos en todas las muestras enviadas.

Cómo funciona la caché de 5.6 según la documentación

Hasta ahora, la caché de GPT tenía un único comportamiento: la API detectaba automáticamente prefijos repetidos de al menos 1,024 tokens y facturaba la parte cacheada a mitad de precio. Por eso clasificamos GPT como «totalmente automático» en nuestra comparativa de caché entre proveedores. La guía de caché de 5.6 lo sustituye por un diseño con 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" }
  ]
}

Estas son las reglas relevantes, resumidas a partir de la guía:

• Un breakpoint marca el final de un prefijo cacheado e incluye ese bloque y todo lo anterior. El modo implicit, que es el predeterminado, sigue colocando automáticamente un breakpoint en el último mensaje. El modo explicit solo cachea lo que se marca.
• Se permiten cuatro escrituras en caché por request. El breakpoint automático del modo implícito consume una, así que quedan tres posiciones para marcadores explícitos en el modo predeterminado y cuatro en el modo explícito. En requests posteriores, los breakpoints de turnos anteriores de la conversación son de solo lectura.
• Se mantiene el mínimo de 1,024 tokens: un prefijo marcado que no alcance esa longitud no se cachea.
• ttl: "30m" garantiza una duración mínima, no máxima («al menos 30 minutos… puede conservarse más tiempo»). Sustituye a prompt_cache_retention, que está deprecado en 5.6. Con él desaparece también la antigua opción de retención ampliada 24h.
• prompt_cache_key permite obtener coincidencias fiables. La guía recomienda una clave estable por tenant o sesión para dirigir las repeticiones a la misma caché, con un límite flexible de unas 15 requests por minuto y clave. Las cachés están aisladas por organización.
• Las escrituras en caché se facturan a 1.25x la tarifa de input en 5.6 y posteriores. Se reportan en el nuevo campo usage.prompt_tokens_details.cache_write_tokens. En 5.x y versiones anteriores, las escrituras eran gratuitas.

GPT-5.5 y los modelos anteriores rechazan los nuevos parámetros con un 400 claro (prompt_cache_options is not supported on this model), por lo que cualquier despliegue debe condicionarse a la versión.

El diseño resultará familiar: marcadores en bloques de contenido, cuatro breakpoints, un recargo de escritura y un historial deslizante de solo lectura. Es la misma estructura que Claude utiliza desde el principio con cache_control. La diferencia está en el TTL: el mínimo garantizado de 30 minutos de OpenAI multiplica por 6 los 5 minutos predeterminados de Claude.

Qué devuelve el medidor

La documentación describe el comportamiento esperado; estos son los resultados que devolvió el medidor del gateway en cada prueba. Los registros completos están en el log de ejecución. Todos los costes que aparecen a continuación cuadran hasta el último decimal con las tarifas de cada tier.

Hay tres resultados que requieren algo más de contexto.

La reutilización parcial funciona y es el principal motivo para adoptar breakpoints. Con un bloque A estable y una cola B sustituida, el medidor solo volvió a facturar la cola: 1,212 tokens leídos a la tarifa cacheada y 1,210 escritos para el nuevo B con el recargo de escritura, sobre un prompt total de 2,431 tokens. El resultado cuadra hasta el último decimal con la tabla de precios. Este es el patrón de prefijos por capas que usan los prompts de Claude: system prompt, tools y documentos, cada uno con su marcador. El modo automático de GPT nunca podía garantizarlo. Hay un matiz: en las repeticiones completas, la longitud coincidente a veces queda por debajo del marcador. En una prueba se reutilizaron 1,897 tokens de una escritura de 2,422. Para presupuestar, conviene usar la tarifa con descuento, no asumir conteos de coincidencia exactos.

El mínimo y los fallos silenciosos son los principales riesgos operativos. Un bloque marcado de 621 tokens no se cacheó en ninguno de los dos intentos. No hubo error ni más indicación en el uso que los valores a cero. Si el «prefijo estable» es un system prompt corto, se paga el precio completo sin recibir aviso alguno. Un fallo también puede llegar sin escritura y a precio completo, igualmente sin avisar. El hit rate es una distribución, no una garantía, independientemente de la ruta que sigan los requests. Hay que leer cached_tokens en producción y configurar alertas, como hacemos en nuestra auditoría de caché de cinco minutos.

El recargo de escritura existe y cambia el punto de equilibrio. Los tokens escritos se facturan exactamente a 1.25x la tarifa de input en los tres tiers: Luna registra $1.25 por millón, Terra $3.125 y Sol $6.25. Todas las pruebas de la ejecución final cuadraron hasta el último decimal. El recargo solo se recupera cuando el prefijo vuelve a leerse. Una escritura que nunca obtiene un hit cuesta un 25% más que no usar caché, el mismo problema que medimos con el recargo de escritura de Claude en el artículo sobre LangChain. Hay que marcar prefijos que realmente vayan a repetirse, no todo lo que parezca estable.

El mínimo de 30 minutos se mantuvo durante el intervalo que probamos. Una relectura con clave realizada 15 minutos después de la escritura se recuperó íntegramente de la caché: 1,313 de 1,313 tokens, a la tarifa del 10%. Superó ampliamente el antiguo intervalo en memoria de entre 5 y 10 minutos. Una segunda prueba con clave y el mismo intervalo dio el mismo resultado. No probamos los 30 minutos completos.

Comparación con la misma carga en GPT-5.5

La comparación justa debe hacerse con el mismo precio. Sol mantiene exactamente la tarifa de gpt-5.5 ($5/$30), por lo que es su sucesor directo. Terra y Luna son los tiers reducidos. El precio base es el mismo, pero las condiciones de caché cambian mucho:

Con el mismo precio base, la mejora está en las condiciones de caché. Un prefijo de 3,000 tokens cuesta $0.0075 por llamada en 5.5 cuando la caché automática acierta, frente a $0.0015 con la caché caliente en Sol: la parte cacheada cuesta 5x menos. El cambio más profundo es el control y la visibilidad. En 5.5, los hits dependen de una detección opaca de prefijos que no se puede activar ni depurar. En 5.6 se puede marcar exactamente qué debe cachearse, dirigir las repeticiones con prompt_cache_key y comprobar cada escritura en usage. Un fallo aparece ahora como un cero en un campo definido por el cliente, no como una ausencia de información. Además, se puede bajar de tier: si 5.5 ofrecía más capacidad de la necesaria, Terra reduce toda la tarifa a la mitad y Luna a una quinta parte. El mismo prefijo caliente baja a $0.00075 y $0.0003. La única ventaja que conserva 5.5 es la retención opcional de 24 horas. Para un batch diario que reutiliza un prefijo enorme, esa opción puede resultar más conveniente. La segunda palanca también puede aumentar el coste de la migración: 5.6 razona por defecto, así que mover una carga de 5.5 sin fijar reasoning_effort añade gasto de output con la misma tarifa base.

La segunda palanca: reasoning effort

La caché determina el coste del input. reasoning_effort controla el output porque los tokens de razonamiento se facturan a la tarifa de output y, a diferencia del prefijo, nunca pueden cachearse. GPT-5.6 admite desde none hasta xhigh en todos los tiers. El anuncio también presenta un nivel max para Sol, pero no está disponible mediante chat completions (400: 'reasoning_effort' does not support 'max' with this model, tanto en Sol como en Terra). Por tanto, xhigh es el máximo práctico en la ruta de API utilizada por gateways y SDKs.

Ejecutamos una matriz de 50 llamadas: cuatro tipos de tarea, seis configuraciones, desde none hasta xhigh más la omisión del parámetro, en Terra y Luna, con una comprobación puntual en Sol. Las tareas fueron clasificar una reseña, extraer un campo de una línea de log, resolver un problema aritmético de varios pasos y generar un pequeño fragmento de código. Las 50 respuestas fueron correctas con todas las configuraciones. Lo que cambió fue el coste. Son llamadas con outputs cortos, de unas decenas de tokens visibles, por lo que unas pocas decenas de tokens de razonamiento a la tarifa de output dominan el coste total. La columna de ratio compara el coste completo de la llamada:

Hay tres conclusiones. Primero, 5.6 se adapta por sí solo: en las dos tareas triviales, ninguna configuración consumió tokens de razonamiento, así que el parámetro no tuvo coste. Segundo, en tareas que parecen requerir más razonamiento, como matemáticas y código, el valor predeterminado razona aunque no mejore el resultado. Omitir el parámetro costó entre 2.5x y 3.5x el precio de none en las tareas de matemáticas y código de Luna y en la de matemáticas de Terra. La ejecución de código en Terra no consumió razonamiento con el valor predeterminado. Sumado todo el grid de Terra y Luna, la omisión costó 1.5x más, con las mismas respuestas correctas. Tercero, las configuraciones intermedias, que no aparecen en la tabla, introducen variabilidad en lugar de funcionar como un control lineal. En la prueba matemática de Terra se consumieron 19 tokens de razonamiento con low, cero con medium, 21 con high y de nuevo cero con xhigh. En la prueba de código de Luna, xhigh consumió 101 frente a 41 con high. Los nombres expresan intenciones, no presupuestos, el mismo comportamiento que medimos en GLM 5.2.

Envía reasoning_effort explícitamente en cada llamada y usa none como valor predeterminado para clasificación, extracción, routing y transformaciones cortas. Solo hay que elevarlo en un punto concreto cuando las evaluaciones demuestren que mejora los resultados, no porque la tarea parezca difícil. Nuestras cuatro tareas representan cargas de API con outputs cortos. El razonamiento puede compensar en problemas realmente complejos y de varios pasos, pero debe decidirse a partir de mediciones.

Las dos palancas se acumulan. Cuando el prefijo ya está caliente, el input de una llamada a Luna cuesta una décima parte del precio de lista. En tareas cortas, el razonamiento predeterminado se convierte entonces en la principal partida restante. La llamada matemática de Luna costó $0.00007 en total con none y $0.00025 al omitir el parámetro. El valor predeterminado añadió por sí solo $0.00018, más del doble del coste completo de la llamada controlada. Si se activa la caché sin fijar el esfuerzo, el ahorro vuelve a perderse por el output.

Recomendaciones según la carga

La decisión tiene ahora varias dimensiones. Estas son nuestras recomendaciones para clientes del gateway:

Independientemente del tipo de carga, hay que enviar un prompt_cache_key estable por tenant o sesión. La documentación lo considera la base para obtener coincidencias fiables. Cada capa marcada debe superar el mínimo de 1,024 tokens y hay que monitorizar cached_tokens, porque existen fallos silenciosos. Las cachés son específicas de cada modelo: un test A/B entre tiers empieza con la caché fría en ambos lados. La otra palanca debe configurarse en el mismo cambio: fija reasoning_effort según la matriz anterior y usa none salvo que una evaluación justifique otra opción.

Al elegir el tier, el descuento del 90% cambia más los números que el propio tier. Una carga que repite un prefijo de 3,000 tokens paga unos $0.30 por cada mil llamadas para ese prefijo con tráfico caliente en Luna y $1.50 en Sol. La diferencia entre tiers para la parte cacheada es menor que para los tokens de output. Por eso conviene elegir el tier según la calidad y el precio del output, y dejar que la caché reduzca el coste del input. Para quienes vienen de gpt-5.5, Sol es el reemplazo directo con la misma tarifa, lecturas de caché 5x más baratas y control explícito sobre cuándo se producen. Se puede bajar a Terra o Luna si las evaluaciones confirman que el tier menor mantiene la calidad; la tarifa se reduce a la mitad o a una quinta parte, además del descuento de caché.

El tokenizer no ha cambiado

Nuestras 24 muestras, que incluyen un pasaje narrativo en nueve idiomas, versiones técnicas y periodísticas en seis de ellos, una función de Python y una tool call en JSON, produjeron el mismo conteo en GPT-5.5, Sol, Terra y Luna en todas las comparaciones completadas. Los presupuestos de tokens y las estimaciones del mínimo de caché calibrados con 5.5 siguen siendo válidos sin cambios. El comportamiento entre idiomas está documentado en nuestro artículo sobre tokenizers por idioma y se aplica a 5.6 tal cual.

Conclusión

• El verdadero recorte de precio de esta versión es el aumento del descuento de caché del 50% al 90%, junto con un TTL mínimo garantizado de 30 minutos. Los precios por tier ocupan el titular, pero las condiciones de caché tienen más impacto en las facturas reales.
• Usa breakpoints explícitos en prompts por capas: la reutilización parcial está medida, no es teórica, y el modelo mental se traslada directamente desde Claude.
• Respeta el mínimo de 1,024 tokens, envía un prompt_cache_key y monitoriza cached_tokens. Existen tanto fallos silenciosos como casos en los que no se cachea nada sin aviso.
• Envía reasoning_effort explícitamente y usa none por defecto: el valor predeterminado no controlado costó 1.5x más en toda la matriz y hasta 3.5x en tareas individuales, con respuestas idénticas.
• xhigh es el máximo accesible; max devuelve 400 mediante chat completions. No hace falta recalibrar el tokenizer respecto a 5.5.

Preguntas frecuentes

¿GPT-5.6 admite caché explícita de prompts como Claude? Sí. Se configura con prompt_cache_options: {"mode": "explicit"} y marcadores prompt_cache_breakpoint en los bloques de contenido. Se permiten hasta cuatro escrituras por request, o tres en modo implícito, donde el breakpoint automático ocupa una posición. En nuestra medición a través de un gateway compatible con OpenAI, un prefijo marcado de 3,012 tokens se escribió en la primera llamada y se recuperó íntegramente a la tarifa cacheada en la segunda.

¿Cuánto cuesta el input cacheado en GPT-5.6? El 10% de la tarifa de input, según nuestras mediciones 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, por lo que la tarifa por token cacheado es 5x menor en 5.6.

¿Es mejor la caché de GPT-5.6 que la de GPT-5.5? Sí, tanto por el descuento como por el control: una tarifa cacheada del 10% frente al 50%, cuatro breakpoints explícitos frente a una detección exclusivamente automática que no se puede activar ni depurar, y un mínimo de 30 minutos con clave frente a entre 5 y 10 minutos sin garantía. La única ventaja que conserva 5.5 es la retención opcional de 24 horas, eliminada en 5.6.

¿Cuánto dura la caché de GPT-5.6? La documentación garantiza al menos 30 minutos; ttl: "30m" es el único valor admitido, aunque la caché puede durar más. Esta opción sustituye al deprecado prompt_cache_retention, incluida la antigua retención ampliada de 24 horas. En nuestras pruebas, las relecturas con clave realizadas 15 minutos después de la escritura se recuperaron íntegramente. No probamos los 30 minutos completos.

¿Necesito prompt_cache_key? Conviene enviarlo. La documentación establece una clave estable por tenant o sesión como base para obtener coincidencias fiables en 5.6, con un límite flexible de unas 15 requests por minuto y clave. Incluirlo no tiene coste. Combinado con la monitorización de cached_tokens, permite verificar que el descuento se está aplicando.

¿Cuánto afecta reasoning_effort al coste de GPT-5.6? En nuestra matriz de 50 llamadas, con cuatro tipos de tarea, seis configuraciones y los tiers Terra y Luna, todas las configuraciones produjeron respuestas correctas. Omitir el parámetro costó en conjunto 1.5x más que none, y llegó a 3.5x en la tarea aritmética. En tareas triviales, como clasificación y extracción, ninguna configuración consumió tokens de razonamiento. Fija none y aumenta el nivel solo si las evaluaciones lo justifican.

¿Está disponible el máximo nivel de reasoning effort en GPT-5.6 Sol? No mediante chat completions. Las requests con reasoning_effort: "max" devuelven un 400 que enumera los valores admitidos, desde none hasta xhigh, tanto en Sol como en Terra.

¿Qué tier de GPT-5.6 debería usar una carga de API? Sol sucede a gpt-5.5 manteniendo el mismo precio: la tarifa sigue siendo $5/$30 y las lecturas cacheadas son 5x más baratas. Terra y Luna son los tiers reducidos, a la mitad y a una quinta parte de ese precio. Cuando el prefijo es estable y usa una clave, el descuento de caché del 90% reduce mucho el peso del input. Baja de tier hasta donde lo permitan las evaluaciones de calidad del output y deja que el tier determine su precio.

Otras guías de costes medidos de esta serie: coste de la transcripción de audio en siete modelos ASR, coste de la generación de imágenes y precios de voz de GPT Realtime.

← Volver al blog