Caché de 12 horas en la API de OpenAI: cuándo reduce el coste de las solicitudes largas

Para un agente que llama a la API varias veces durante una jornada laboral, volver a enviar instrucciones largas influye en el coste. El 20 de octubre de 2026, OpenAI añadió a Responses API la opción de elegir una duración de caché de 12 horas: las instrucciones, herramientas y el contexto compartidos pueden seguir disponibles para reutilizarse entre solicitudes separadas por varias horas. OpenAI indica una tarifa de escritura 2,5 veces superior al precio habitual de los tokens de entrada; se trata de la tarifa total de escritura, no de un recargo añadido a esta. El ahorro depende de que se reutilice el prefijo y del precio de lectura de los tokens almacenados en caché. El anuncio en el registro de cambios de OpenAI está fechado el 20 de octubre de 2026.

Esta duración está pensada para flujos de trabajo de varias etapas: por ejemplo, un agente puede analizar documentos por la mañana y retomar la tarea más tarde con las mismas instrucciones y herramientas. Para decidir si conviene activar la duración de 12 horas, compara el coste de escritura con el gasto de las lecturas repetidas y ten en cuenta cuántas solicitudes reutilizan realmente el mismo prefijo.

Qué se almacena en caché

El almacenamiento en caché de prompts reutiliza un fragmento inicial coincidente de la entrada. Las solicitudes posteriores deben conservarlo sin cambios; los datos variables conviene situarlos después de la parte estable. La guía de OpenAI sobre el almacenamiento en caché de prompts indica que, para GPT‑5.6 y modelos posteriores en Responses API, se puede configurar un TTL de `30m` o `12h`. Las doce horas son el periodo mínimo durante el cual la entrada debe seguir disponible para su lectura desde la caché; no es una promesa de que se elimine exactamente al cabo de 12 horas. La disponibilidad y los parámetros dependen del modelo.

Las instrucciones del sistema, las definiciones de herramientas y las reglas de procesamiento estables son adecuadas para el prefijo permanente. La pregunta actual, los identificadores de la tarea y los datos recientes se pueden añadir después. Si cambian las primeras partes de la solicitud, el prefijo coincidente será más corto y puede disminuir el volumen de tokens reutilizados.

Cómo calcular si resulta rentable

Supongamos que el prefijo estable contiene P tokens, se envía N veces, el precio de un token de entrada normal es C y la tarifa de lectura desde la caché para el modelo elegido es R. Con una escritura inicial y aciertos de caché en todas las solicitudes posteriores, el coste de ese prefijo sería aproximadamente 2,5PC + (N−1)PR. Sin caché, enviarlo costaría NPC. Este cálculo solo se refiere al prefijo estable: considera por separado la parte variable de la solicitud, los fallos de caché y las escrituras adicionales. La tarifa de lectura depende del modelo; por ejemplo, la documentación indica que para GPT‑6.1 Sol es 0,05 veces el precio habitual del token de entrada y que para GPT‑5.6 y modelos posteriores es 0,1.

En este modelo simplificado, la caché empieza a ahorrar en el prefijo reutilizado cuando 2,5C + (N−1)R < NC. El punto de equilibrio real depende de los aciertos efectivos, las escrituras repetidas y la tarifa concreta. Si las solicitudes son poco frecuentes, las instrucciones cambian a menudo o el prefijo es único en cada ocasión, el coste adicional de escritura puede superar el ahorro en lectura.

Prueba con tu carga de trabajo

1. Establece un escenario de referencia. Usa solicitudes típicas, la longitud del prefijo estable, los intervalos entre llamadas y el gasto sin un TTL de 12 horas.
2. Separa lo permanente de lo variable. Mantén al principio las instrucciones compartidas y los esquemas de herramientas, y coloca después los datos del usuario y la tarea actual.
3. Compara solicitudes equivalentes. Calcula las escrituras, el volumen de tokens de entrada almacenados en caché y el coste total para el modelo y la duración elegidos.
4. Evalúa el ciclo de trabajo completo. Ten en cuenta los fallos de caché, las escrituras repetidas tras el vencimiento y los casos en que un cambio en el prefijo impide reutilizarlo.

Las métricas de respuesta de la API permiten comprobar el volumen real de tokens de entrada leídos desde la caché y de escrituras; los datos incluidos en los informes dependen del modelo. La duración configurable de 12 horas es adecuada para un prefijo grande y estable que se reutiliza con varias horas de diferencia. Para solicitudes cortas o que se repiten pocas veces, mide primero las escrituras, los aciertos y el coste total con tu propio tráfico.