Caché de prompts de OpenAI (octubre de 2026): cómo funciona, precios y ROI
La caché de prompts de OpenAI está activada por defecto: cuando una solicitud empieza con el mismo prefijo (al menos 1.024 tokens en GPT-5.6 y posteriores) que una solicitud reciente, OpenAI reutiliza el cálculo guardado y factura esos tokens a la tarifa de entrada en caché, entre un 90 % y un 95 % más barata que la entrada normal. En GPT-5.6 y posteriores también pagas una escritura en caché única: 1,25 veces la tarifa de entrada para la duración predeterminada de 30 minutos o 2,5 veces para 12 horas, a 25 de octubre de 2026. Si un prefijo se reutiliza aunque sea una sola vez dentro de su vigencia, la caché ya sale más barata que enviarlo dos veces.
Esta guía explica cómo funciona la caché de OpenAI, cuánto cuesta en los modelos actuales, cómo controlarla con breakpoints y TTL, cómo medir el ahorro y cómo se compara con la caché de Anthropic y Gemini. Todas las tarifas proceden de la guía de caché de prompts de OpenAI y de la página de precios de la API de OpenAI, consultadas el 25 de octubre de 2026.
Precios de la caché de prompts de OpenAI
Precios del nivel estándar por 1 M de tokens:
| Modelo | Entrada | Entrada en caché (lectura) | Escritura 30 min | Escritura 12 h | Salida |
|---|---|---|---|---|---|
| gpt-6-astra | 10,00 $ | 1,00 $ | 12,50 $ | 25,00 $ | 50,00 $ |
| gpt-6.1-sol | 2,00 $ | 0,10 $ | 2,50 $ | 5,00 $ | 10,00 $ |
| gpt-6-luna | 0,10 $ | 0,01 $ | 0,125 $ | 0,25 $ | 0,50 $ |
| gpt-5.6-sol | 4,00 $ | 0,40 $ | 5,00 $ | 10,00 $ | 20,00 $ |
Una lectura de caché cuesta 0,1 veces la tarifa de entrada sin caché en la mayoría de los modelos y 0,05 veces en GPT-6.1 Sol. El nivel Batch reduce a la mitad todas las cifras de esta tabla y el modo Fast las duplica. Los endpoints regionales de residencia de datos tienen un recargo del 10 % para los modelos lanzados a partir del 5 de marzo de 2026.
Un punto que se suele malinterpretar: el precio de escritura en caché no es un cargo adicional sobre la entrada. Cada token de entrada se factura una sola vez, a la tarifa sin caché, de lectura en caché o de escritura en caché. Una escritura de 30 minutos cuesta un 25 % más que la entrada normal para esos tokens, y cada acierto posterior cuesta el 10 % (o el 5 %).
Cómo funciona la caché de prompts de OpenAI
Cuando un modelo lee tu prompt, calcula estados clave-valor (KV) para cada token. La caché de prompts guarda esos estados para un prefijo reutilizable, es decir, el comienzo del prompt que no cambia. Si una solicitud posterior empieza exactamente con el mismo prefijo y encuentra una entrada de caché coincidente, el modelo se ahorra recalcularlo, lo que reduce tanto el coste como el tiempo hasta el primer token.
El prefijo en caché abarca todo lo que OpenAI renderiza antes de que cambie tu contenido: el contenido de sistema oculto, los mensajes de developer, las definiciones de herramientas y el historial de conversación, incluidos texto, imágenes, documentos y audio compatible. La coincidencia debe ser exacta. Si algo cambia antes de un breakpoint, como una marca de tiempo en el prompt de sistema, una lista de herramientas reordenada o una imagen distinta, todo lo que va después de ese cambio es un fallo de caché.
Reglas clave en GPT-5.6 y posteriores:
- Longitud mínima: un prefijo debe tener al menos 1.024 tokens para guardarse en caché. Los tokens de sistema ocultos de OpenAI no cuentan.
- Breakpoints: un breakpoint marca el final de un prefijo que puede escribirse en caché. En modo implícito (el predeterminado), OpenAI coloca uno al final del último mensaje elegible. En modo explícito eliges dónde van con
prompt_cache_breakpoint. - Hasta cuatro escrituras por solicitud: cada solicitud puede crear hasta cuatro escrituras en caché, así que puedes almacenar capas que cambian a distinta velocidad.
- Vigencia: define
prompt_cache_options.ttlcomo"30m"(predeterminado) o"12h"en la Responses API. Las lecturas cuestan lo mismo en ambos casos.
En los modelos anteriores a GPT-5.6 solo existe la caché implícita. La retención se controla con prompt_cache_retention: in_memory mantiene las entradas durante unos 5–10 minutos de inactividad (hasta una hora) y 24h lo amplía hasta 24 horas. Las organizaciones sin Zero Data Retention usan 24h por defecto; las organizaciones con ZDR, in_memory. En estos modelos antiguos, un prompt_cache_key estable ayuda a dirigir solicitudes relacionadas a la misma caché. OpenAI recomienda mantener cada clave en unas 15 solicitudes por minuto y repartir el tráfico más intenso entre varias claves.
Cuándo compensa la caché
La guía de OpenAI ofrece las cuentas básicas. Con una lectura a 0,1x y una escritura a 1,25x, escribir un prefijo una vez y reutilizarlo una vez cuesta 1,35 veces su precio de entrada normal, frente a 2 veces si se envía dos veces. Diez solicitudes con una escritura y nueve lecturas cuestan 2,15x, frente a 10x sin caché.
| Solicitudes que comparten el prefijo | Sin caché | Caché de 30 minutos | Caché de 12 horas | Ahorro con caché de 30 minutos |
|---|---|---|---|---|
| 1 | 1,00× | 1,25× | 2,50× | −25 % |
| 2 | 2,00× | 1,35× | 2,60× | 33 % |
| 10 | 10,00× | 2,15× | 3,40× | 79 % |
| 100 | 100,00× | 11,15× | 12,40× | 89 % |
La vigencia de 12 horas solo tiene sentido cuando el intervalo entre solicitudes supera los 30 minutos pero el prefijo se sigue reutilizando varias veces, por ejemplo un manual de producto extenso que una herramienta interna de poco tráfico consulta a lo largo de la jornada.
OpenAI también explica cuándo conviene rellenar un prefijo corto hasta el mínimo. Con un mínimo de 1.024 tokens, lectura a 0,1x y escritura a 1,25x, rellenar sale más barato cuando tu prefijo original supera 102,4 + 1.177,6 / N tokens, donde N es el número de solicitudes. Con 10 solicitudes, ampliar a 1.024 tokens un prefijo de 221 tokens o más ya compensa.
Un ejemplo práctico
Supongamos que un asistente de soporte con gpt-6.1-sol atiende 50.000 solicitudes al día. Cada solicitud envía un prefijo estable de 8.000 tokens (instrucciones, definiciones de herramientas y documentos de políticas) y un mensaje de usuario de 500 tokens, y recibe una respuesta de 400 tokens. El tráfico es constante, así que la caché de 30 minutos se reescribe unas 48 veces al día.
| Partida de coste diario | Sin caché | Con caché explícita |
|---|---|---|
| Prefijo estable | 400 M × 2,00 $ = 800,00 $ | escrituras: 0,38 M × 2,50 $ = 0,96 $; lecturas: 399,6 M × 0,10 $ = 39,96 $ |
| Mensaje del usuario | 25 M × 2,00 $ = 50,00 $ | 25 M × 2,00 $ = 50,00 $ |
| Salida | 20 M × 10,00 $ = 200,00 $ | 20 M × 10,00 $ = 200,00 $ |
| Total | 1.050,00 $ | ≈ 290,92 $ |
Es una reducción de alrededor del 72 % en la factura diaria. La partida de salida es igual en ambas columnas, así que, una vez que la caché funciona, acortar las respuestas es la siguiente palanca.
¿Por qué el modo explícito aquí? En modo implícito el breakpoint está al final del último mensaje, de modo que los 500 tokens variables del usuario también se escribirían en caché a 1,25x cada vez. En este ejemplo eso añade unos 12,50 $ al día. El modo explícito permite terminar la escritura justo después del prefijo estable, así que el mensaje del usuario se factura a la tarifa de entrada normal.
Cómo configurarla
No necesitas código para aprovechar la caché implícita. Para controlarla, usa la Responses API. Esta solicitud guarda en caché las instrucciones compartidas durante 12 horas y el contexto de la sesión durante 30 minutos, y deja la pregunta actual sin caché:
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6.1-sol",
"prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
"input": [
{ "role": "developer", "content": [
{ "type": "input_text", "text": "<shared instructions and policy docs>",
"prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" } } ] },
{ "role": "user", "content": [
{ "type": "input_text", "text": "<session context>",
"prompt_cache_breakpoint": { "mode": "explicit" } },
{ "type": "input_text", "text": "What is the refund window for annual plans?" } ] }
]
}'
Lee los campos de caché de cada respuesta y regístralos:
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(model="gpt-6.1-sol", input=[...]) # same input as above
d = resp.usage.input_tokens_details
print("input:", resp.usage.input_tokens)
print("cache reads:", d.cached_tokens)
print("cache writes:", d.cache_write_tokens)
hit_rate = d.cached_tokens / max(resp.usage.input_tokens, 1)
print(f"token cache-hit rate: {hit_rate:.0%}")
En los modelos que admiten prompt_cache_options, cache_write_tokens_details divide las escrituras en ttl_30m_tokens y ttl_12h_tokens. El valor de cached_tokens se redondea a la baja a un múltiplo de 128. OpenAI ofrece además un Prompt Caching Dashboard para seguir la tasa de aciertos y una herramienta Prompt Cache Diagnostics que explica los fallos.
Reglas de diseño de prompts que aumentan los aciertos
- Lo estático primero, lo dinámico al final. Coloca arriba las instrucciones, los esquemas de herramientas, los ejemplos few-shot y los documentos de referencia. Coloca abajo el mensaje del usuario, los fragmentos recuperados y todo lo que lleve fecha o ID.
- Congela la lista de herramientas. Cambiar las definiciones rompe el prefijo. Si distintas solicitudes necesitan herramientas distintas, mantén las definiciones estables y cambia cuáles se pueden invocar.
- Añade, no reescribas. En chats de varios turnos, agrega los nuevos turnos al final. Resumir o editar turnos anteriores invalida la caché.
- Mantén estables los ajustes. El modelo, los ajustes de razonamiento y otras opciones de la solicitud pueden cambiar el prefijo renderizado. Fíjalos para el tráfico en caché.
- Vigila los fallbacks. Si cambias a otro modelo o proveedor, empiezas con la caché vacía. Nuestro manual de estrategias de fallback de modelos explica cómo hacer failover sin perder toda la localidad de caché.
Caché de prompts: OpenAI vs Anthropic vs Gemini
La caché no es portable entre proveedores. La mecánica y los precios cambian:
| OpenAI (GPT-5.6+) | Anthropic Claude | Google Gemini | |
|---|---|---|---|
| Por defecto | Automática | Opcional con cache_control (automática o por bloque) |
Caché implícita automática en Gemini 2.5 y posteriores |
| Prefijo mínimo | 1.024 tokens | 512 tokens en los modelos actuales | 4.096 tokens en Gemini 4 Argon y 3.8 Flash |
| Coste de escritura | 1,25× (30 min) o 2,5× (12 h) | 1,25× (5 min) o 2× (1 h) | Sin cargo de escritura en la implícita; la explícita añade almacenamiento por hora |
| Coste de lectura | 0,1× (0,05× en GPT-6.1 Sol) | 0,1× (0,05× en Opus 5.5 y Sonnet 5.5) | p. ej., 0,10 $ frente a 2,00 $ de entrada en Gemini 4 Argon |
| Campo de uso | cached_tokens, cache_write_tokens |
cache_read_input_tokens, cache_creation_input_tokens |
total_cached_tokens |
Fuentes: la documentación de caché de prompts de Anthropic, los precios de la API de Claude, la caché de contexto de Gemini y los precios de la API de Gemini, todas consultadas el 25 de octubre de 2026. Gemini 4 Argon solo admite caché implícita. Los objetos de caché explícita funcionan en los modelos Gemini 3 y 2.5 compatibles mediante generateContent, con almacenamiento facturado por millón de tokens y hora (por ejemplo, 0,50 $ en Gemini 3.8 Flash hasta el 31 de diciembre de 2026). DeepSeek también usa caché automática; consulta la guía de caché de DeepSeek.
Verificación de ROI de la caché en siete días
Antes de dar la caché por un éxito, mídela con tráfico real:
- Día 1: elige un flujo de alto volumen con un prefijo compartido largo. Registra por solicitud los tokens de entrada,
cached_tokens,cache_write_tokens, los tokens de salida y la latencia. - Días 2–3: mueve todo el contenido estático arriba y elimina de él los valores dinámicos. Compara la tasa de aciertos por token (tokens en caché ÷ tokens de entrada) antes y después.
- Días 4–5: si hay muchas escrituras y pocas lecturas, tu tráfico es demasiado disperso para entradas de 30 minutos. Prueba
"12h"en la capa estable o consolida el prefijo para que más solicitudes lo compartan. - Días 6–7: calcula el coste real por respuesta aceptada, no solo por token. Una solicitud más barata que los usuarios rechazan no es un ahorro.
Para una carga estable de chat o agentes, buenos objetivos son una tasa de aciertos por token superior al 60 % y al menos 10 lecturas por cada escritura. Nuestra guía de observabilidad de APIs de LLM y la guía de paneles de uso de tokens muestran cómo crear estas vistas.
Dónde encaja Flatkey
Flatkey es un router compatible con OpenAI con una sola clave y un solo saldo para OpenAI, Claude, Gemini, DeepSeek, Qwen y otros modelos. La caché de cada proveedor sigue dependiendo de sus propias reglas, así que mantén los prompts estables por modelo y evita rotar de modelo en cada solicitud si quieres aciertos de caché. Empieza con la guía rápida del router, consulta las tarifas actuales en precios de Flatkey y revisa nuestra guía de optimización de costes de APIs de IA para otras formas de reducir el gasto.
Preguntas frecuentes
¿La caché de prompts de OpenAI es automática?
Sí. La caché de prompts está activada por defecto en los modelos compatibles de OpenAI y no necesitas cambiar tu código para obtener aciertos. En GPT-5.6 y posteriores puedes pasar al modo explícito y elegir breakpoints con prompt_cache_breakpoint.
¿Cuánto ahorra la caché de prompts de OpenAI?
La entrada en caché cuesta 0,1 veces la tarifa normal en la mayoría de los modelos actuales y 0,05 veces en GPT-6.1 Sol, un descuento del 90–95 % sobre la parte en caché. El ahorro total depende de qué parte de cada prompt es un prefijo compartido y de la frecuencia con que se reutiliza.
¿Cuál es la longitud mínima del prompt para la caché?
1.024 tokens en GPT-5.6 y posteriores. En modelos anteriores varía según los ajustes de la solicitud. Los prefijos más cortos se procesan con normalidad, sin error.
¿Cuánto dura la caché de prompts de OpenAI?
En GPT-5.6 y posteriores, las entradas duran al menos 30 minutos por defecto, o al menos 12 horas si defines ttl como "12h". En modelos anteriores, in_memory las mantiene unos 5–10 minutos de inactividad, hasta una hora, y 24h puede conservarlas hasta 24 horas.
¿La caché de prompts reduce la latencia?
Sí. Reutilizar un prefijo en caché evita recalcularlo, lo que reduce el tiempo hasta el primer token, sobre todo con prompts largos.
¿Pago por escribir en la caché?
En GPT-5.6 y posteriores, sí: 1,25 veces la tarifa de entrada para una escritura de 30 minutos o 2,5 veces para 12 horas. Esto sustituye al cargo de entrada normal de esos tokens; no se suma a él.
¿Qué es prompt_cache_key?
Un parámetro opcional que agrupa solicitudes relacionadas para que se dirijan a la misma caché. En modelos anteriores a GPT-5.6 mejora la tasa de aciertos; OpenAI recomienda unas 15 solicitudes por minuto por clave.
Fuentes
- Guía de caché de prompts de OpenAI (consultada el 25 de octubre de 2026)
- Precios de la API de OpenAI (consultada el 25 de octubre de 2026)
- Caché de prompts de Anthropic (octubre de 2026)
- Precios de la API de Claude (octubre de 2026)
- Caché de contexto de Gemini (octubre de 2026)
- Precios de la API de Gemini (octubre de 2026)
- Caché de contexto de DeepSeek (octubre de 2026)
