Caché de prompts de OpenAI de 12 horas: cuándo compensa pagar 2.5×

Usa la caché de prompts de OpenAI de 12 horas para un prefijo estable que tu agente reutiliza tras pausas largas; mantén el contenido cambiante de la sesión en 30m o fuera de las escrituras en caché. Si la alternativa exige una nueva escritura de 30m en cada solicitud, una sola escritura de 12h sale más barata a partir de la tercera solicitud total —la segunda reutilización—, siempre que el prefijo siga coincidiendo. Si 30m ya produce aciertos de caché en todas las solicitudes, la duración mayor añade costo sin reducir el precio de lectura.

¿Cuánto cuestan 30m y 12h?

La opción 12h permite acceder durante más tiempo a la tarifa de entrada en caché, a cambio de duplicar el precio de escritura predeterminado. El registro de cambios de la API del 20 de octubre de 2026 anunció esta opción para Responses; la guía de caché de prompts documenta las siguientes reglas para GPT-5.6 y posteriores, comprobadas a fecha de 2026-10-24.

Cargo de entrada	Multiplicador respecto a la entrada ordinaria	GPT-6.1 Sol, USD por 1M tokens
Entrada ordinaria	1×	$2.00
Escritura de `30m`, predeterminada	1.25×	$2.50
Escritura de `12h`	2.5×	$5.00
Lectura de caché, con cualquiera de las duraciones	0.1× en la mayoría de los modelos; 0.05× en GPT-6.1 Sol	$0.10

Estas son las tarifas totales de escritura. Un token facturado como escritura de 12h cuesta 2.5× la entrada ordinaria; no se cobra la entrada ordinaria más un recargo adicional de 2.5×.

La columna en dólares usa los precios Standard actuales de OpenAI para gpt-6.1-sol, con prompts de hasta 272K tokens de entrada y sin recargo por procesamiento regional. La salida cuesta $10.00 por 1M tokens. Los prompts más largos, otros niveles de servicio y el procesamiento regional pueden cambiar las tarifas; consulta las condiciones de precios del modelo que correspondan antes de aplicar los cálculos siguientes.

El prefijo reutilizable debe contener al menos 1,024 tokens de entrada visibles. Una solicitud grande con un inicio breve que no cambia no hace que ese inicio cumpla automáticamente los requisitos para almacenarse en caché.

¿Cuándo compensa el precio de escritura más alto?

Cuenta las escrituras que evita la mayor duración. Sea B el costo de entrada ordinaria de tu prefijo sin cambios, n el número total de solicitudes, r el multiplicador de lectura y k el número de escrituras de 30m, incluida la primera.

Suponiendo que cada escritura o acierto cubre todo ese prefijo, y que una escritura de 12h va seguida de lecturas correctas:

12h cost = B × [2.5 + (n - 1) × r]
30m cost = B × [1.25 × k + (n - k) × r]
No-cache cost = B × n

Tanto con r = 0.1 como con r = 0.05, la caché de mayor duración cuesta menos que la entrada sin caché cuando n = 3. Frente a la caché predeterminada, resulta más barata cuando k >= 3, siempre que la política de 12h siga necesitando una sola escritura. La condición es evitar dos escrituras posteriores de corta duración, no simplemente acumular muchos aciertos.

Si ambas políticas escriben una vez y después aciertan en todas las solicitudes, 12h sigue costando 1.25 × B más. Por eso, en conversaciones interactivas frecuentes hay pocos motivos para pagar la escritura de mayor duración, salvo que también se retomen tras pausas que obliguen a reescribir el prefijo.

Una pausa de más de 30 minutos abre una oportunidad de ahorro, pero no demuestra que vaya a producirse un fallo de caché. OpenAI puede conservar las entradas más allá de su duración mínima, y una lectura de 30m renueva la cobertura durante al menos otros 30 minutos. Para estimar el costo de una carga de trabajo existente, usa el número de escrituras observado.

Como estimación concreta, considera un prefijo de 10,000 tokens en GPT-6.1 Sol con precios Standard: B = $0.02 y r = 0.05. Envía 12 solicitudes, una cada hora desde la hora 0 hasta la 11, sin cambiar el prefijo.

Comportamiento de caché supuesto	Costo de entrada del prefijo en las 12 solicitudes
Sin caché: 12 entradas ordinarias	$0.240
`30m`: las 12 solicitudes requieren escrituras	$0.300
`12h`: una escritura y 11 lecturas	$0.061
`30m`: una escritura y 11 lecturas	$0.036

Las dos filas de 30m muestran por qué el intervalo entre solicitudes, por sí solo, no determina el ahorro. La fila en la que todas las solicitudes escriben es un supuesto, no un resultado inevitable al solicitar una vez por hora. Estas estimaciones excluyen los sufijos cambiantes, los tokens de salida y cualquier cargo por herramientas; no proceden de facturas reales.

Por qué aplicar 12h a toda la solicitud puede costar más

Configurar prompt_cache_options.ttl: "12h" para toda la solicitud también afecta al punto de corte implícito, es decir, al límite hasta el que se aplica la caché automáticamente. Con el valor predeterminado mode: "implicit", el contenido nuevo de la conversación que cumpla los requisitos puede generar una escritura a 2.5× en cada turno, aunque el prefijo anterior se lea a un precio reducido.

En un agente que acumula resultados de herramientas y mensajes del usuario, ese sufijo creciente puede superar el ahorro obtenido con el inicio estable. Un porcentaje alto de aciertos de caché no basta para saber si la política resulta económica.

Elige una de estas configuraciones:

Material compartido estable y contexto de sesión reutilizable: establece 30m como valor predeterminado de la solicitud y añade una excepción de 12h al final del material compartido.
Material estable y preguntas de un solo uso: usa mode: "explicit" y deja la pregunta cambiante después del último punto de corte explícito.
Una conversación cuyo contexto más reciente se reutilizará pronto: conserva mode: "implicit" con 30m como valor predeterminado de la solicitud y un punto de corte de 12h para el prefijo compartido.

Un punto de corte cubre todo el prefijo que lo precede. En una solicitud sin caché previa, con un punto de corte de 12h en los 2,000 tokens y otro de 30m en los 5,000, se facturan 2,000 tokens como escrituras de larga duración y 3,000 como escrituras de corta duración. Si sitúas el punto de corte de 12h en el límite posterior de 5,000 tokens, los 5,000 tokens reciben la tarifa de escritura de mayor duración. Cada token se factura una sola vez, con la duración de escritura más larga seleccionada que lo cubra.

También importan dos cambios de duración. Ampliar una cobertura válida de 30m a 12h genera una nueva escritura de larga duración, sin descontar lo pagado por la anterior. Si una solicitud con 30m lee un prefijo cubierto por una entrada de 12h aún válida, esos tokens se cobran a la tarifa de lectura, sin reiniciar el plazo de 12 horas ni añadir una escritura. Estas reglas de solapamiento y duración aconsejan elegir la política antes de cargar un prefijo grande en la caché.

Configura 12h y 30m en una misma solicitud de Responses

Usa 30m como valor predeterminado de la solicitud y puntos de corte explícitos para separar el material de referencia compartido, el contexto de la sesión y la pregunta actual. Este ejemplo envía la solicitud directamente a la API Responses de OpenAI y muestra tanto el texto generado como los datos de uso necesarios para revisar la facturación.

Necesitas Bash, curl, jq y una clave de API de OpenAI con acceso a gpt-6.1-sol. Prepara estos archivos en el directorio actual:

shared-context.md: instrucciones de ingeniería y material de referencia útiles que reutilizarás durante el día, con al menos 1,024 tokens de entrada visibles.
session-context.md: el contexto del despliegue o de la pull request actual que prevés reutilizar durante esta sesión.

No cambies ninguno de los archivos entre las dos llamadas del ejemplo. Cuando read espere una entrada, pega tu clave de API y pulsa Enter; la terminal no la mostrará. La autenticación sigue la guía de inicio rápido de la API de OpenAI.

set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY

cache_request() {
  jq -n \
    --rawfile shared ./shared-context.md \
    --rawfile session ./session-context.md \
    --arg question "$1" \
    '{
  model: "gpt-6.1-sol",
  service_tier: "default",
  reasoning: {effort: "low"},
  prompt_cache_options: {mode: "explicit", ttl: "30m"},
  input: [
    {
      role: "developer",
      content: [{
        type: "input_text",
        text: $shared,
        prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
      }]
    },
    {
      role: "user",
      content: [
        {
          type: "input_text",
          text: $session,
          prompt_cache_breakpoint: {mode: "explicit"}
        },
        {type: "input_text", text: $question}
      ]
    }
  ]
}' |
  curl --silent --show-error --fail-with-body \
    https://api.openai.com/v1/responses \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @- |
  jq '{id, status, service_tier,
  text: ([.output[]? | .content[]? |
    select(.type == "output_text") | .text] | join("\n")),
  usage, error}'
}

cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."

El primer bloque de contenido sustituye el valor predeterminado de la solicitud por "ttl": "12h". El bloque de sesión no especifica su propio TTL y hereda "30m". Como la solicitud usa exclusivamente puntos de corte explícitos, la pregunta final no genera cargos de escritura en caché; sí se cobra como entrada ordinaria.

Para un prefijo que cumpla los requisitos y aún no esté en caché, la primera respuesta completada debería registrar escrituras de larga duración en usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens. La segunda debería mostrar cached_tokens > 0 y ninguna escritura nueva de larga duración, siempre que el prefijo y su cobertura sigan siendo válidos. El campo text devuelto contiene la respuesta utilizable. Repetir la solicitud de inmediato permite comprobar la coincidencia y la contabilidad; para evaluar el ahorro tras pausas largas, usa los intervalos reales de producción.

Si recibes 400 invalid_request_error, comprueba los valores exactos de TTL, el modelo elegido y el endpoint de Responses. Si ambas llamadas devuelven cero tokens en caché, revisa primero la longitud del prefijo y después compara los archivos, el modelo, la configuración y la ubicación de los puntos de corte. Los cambios anteriores al punto de corte compartido —incluidas las modificaciones en las definiciones de herramientas al añadirlas— pueden impedir la reutilización.

Para probar una referencia de costo sin caché, conserva mode: "explicit" y elimina todos los prompt_cache_breakpoint. El esquema oficial de la solicitud documenta que el modo explícito sin marcadores no usa caché de prompts.

Calcula el cargo de entrada a partir de usage

Trata la entrada ordinaria, las lecturas de caché y las dos clases de escritura como categorías que no se solapan. El total cache_write_tokens ya incluye los componentes ttl_30m_tokens y ttl_12h_tokens; cobrar los tres duplicaría las escrituras. Los tokens facturados por ampliar la duración a 12h pertenecen a las escrituras y quedan fuera de cached_tokens.

El ejemplo de contabilidad del uso de OpenAI tiene esta estructura:

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 4000,
      "cache_write_tokens": 7000,
      "cache_write_tokens_details": {
        "ttl_30m_tokens": 3000,
        "ttl_12h_tokens": 4000
      }
    }
  }
}

Sea I el valor de input_tokens, R el de cached_tokens, y W30 y W12 los dos recuentos de escritura por TTL. Calcula la entrada ordinaria como U = I - R - W30 - W12; en este caso son 1,000 tokens.

Para un precio de entrada ordinaria P en USD por 1M tokens y un multiplicador de lectura de caché r:

Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000

El ejemplo hipotético de la documentación, con P = $1 y r = 0.1, da:

(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515

Para el mismo uso con las tarifas Standard de GPT-6.1 Sol, sustituye P = $2 y r = 0.05: el cargo de entrada es $0.02990. Añade por separado la salida y cualquier otro cargo aplicable. Este cálculo aísla la facturación de entrada; no estima el costo total de completar una tarea de programación.

Registra el ID de la respuesta, la hora, el modelo, el service_tier real y estos recuentos de tokens. Si un cliente omite el desglose por TTL, inspecciona el JSON original antes de calcular los costos con distintas duraciones; la ausencia de contadores no demuestra que no haya escrituras. Suma los cargos en dólares de un día representativo en lugar de elegir una política a partir de un único porcentaje de aciertos.

Por último, 12h establece una duración mínima durante la cual se puede aplicar la tarifa de lectura de caché. No fija un plazo de eliminación, no cambia la política que rige la retención máxima de los datos ni garantiza menor latencia en cada solicitud.

¿En qué se diferencia de Codex, Work y Anthropic?

Separa la facturación de la API de las cuotas de uso incluidas al iniciar sesión en un producto. En su publicación del 21 de octubre de 2026, Tibo Sottiaux describió la caché de los usuarios con sesión iniciada en Codex y Work como permanente y afirmó que retomar conversaciones antiguas produciría un acierto de caché. Esa declaración se refiere a las sesiones de esos productos; no define un TTL de API ni convierte una suscripción en ilimitada.

La documentación oficial de precios de Codex indica por separado que la facturación mediante créditos de Codex no tiene un cargo adicional por escritura en caché, mientras que el uso con una clave de API sigue los precios de la API. Si ejecutas Codex con una clave de API, calcula el presupuesto según esas reglas, sin trasladar a la API una promesa sobre el producto con sesión iniciada.

Para Claude, las opciones documentadas a fecha de 2026-10-24 son una caché predeterminada de 5 minutos con escrituras a 1.25× y una opcional de 1 hora con escrituras a 2×. Los descuentos de lectura varían según el modelo: Claude Opus 5.5 y Sonnet 5.5 usan 0.05×; las demás tarifas aparecen en la tabla de precios de Anthropic. Las lecturas correctas renuevan la duración sin otro recargo de escritura, y las solicitudes con distintos TTL exigen colocar los bloques de mayor duración antes de los de menor duración.

Si hay pausas repetidas de varias horas y tu aplicación ya usa un modelo compatible, prueba primero la política de 12h de OpenAI para el prefijo estable. Para una sesión que permanece activa continuamente, empieza por la caché más corta. Comparar proveedores exige considerar sus precios base reales, el uso de salida y el comportamiento de caché observado; la duración y los multiplicadores de escritura, por sí solos, no permiten determinar cuál completa la tarea por menos dinero.