Prompt caching de OpenAI y Claude: cómo funciona, TTL, precio, por qué no funciona y cómo comprobarlo

El prompt caching (caché de prompts) reutiliza el cálculo de la parte de una solicitud que coincide exactamente con el comienzo de una solicitud anterior (el prefijo), de modo que esa parte de la entrada se procesa más barata y más rápido. Tanto la API de OpenAI como la API de Claude lo ofrecen, pero cómo se activa, cuánto dura la caché, cuánto cuesta escribir en ella y cómo se comprueba si funciona cambian mucho entre una y otra. Si diseñas para ambas con las mismas suposiciones, puedes acabar con una caché que funciona en un lado mientras, en el otro, pagas la escritura en cada solicitud sin conseguir nunca un acierto.

Este artículo compara el prompt caching de OpenAI y el de Anthropic a partir del texto original de las páginas "Prompt caching", "Prompt cache diagnostics" y "Pricing" de OpenAI, y "Prompt caching", "Cache diagnostics", "Pricing" y "Rate limits" de Anthropic. Explica en qué se diferencian las dos especificaciones, cómo conseguir aciertos de caché y cómo confirmar que los estás obteniendo. Todas las cifras se comprobaron en las páginas originales el 3 de octubre de 2026. Para una visión general de cómo reducir el gasto en API (elección de modelo, procesamiento por lotes, control de la salida, etc.), consulta nuestro artículo "Cómo ahorrar en gasto y tokens de IA".

1. Qué es el prompt caching: reutilizar un prefijo idéntico

Cada vez que un modelo de lenguaje lee su entrada, calcula valores intermedios para cada token (los tensores KV, de clave y valor). El prompt caching guarda esos valores desde el principio del prompt hasta cierto punto y se salta el cálculo cuando la siguiente solicitud empieza exactamente con los mismos tokens. La guía de OpenAI aclara que lo que se guarda son los valores KV, no los tokens en sí.

La clave es que solo se puede reutilizar la parte que coincide desde el mismo comienzo. En las dos solicitudes siguientes, solo las instrucciones y los documentos son reutilizables.

Solicitud 1: [Instrucciones 5,000 tokens][Documentos 20,000 tokens][Pregunta A]
Solicitud 2: [Instrucciones 5,000 tokens][Documentos 20,000 tokens][Pregunta B]
             └──────────────── idéntico hasta aquí ────────────────┘└ cambia   ┘
→ Los 25,000 tokens de instrucciones + documentos se pueden reutilizar

Solicitud 3: [Fecha de hoy][Instrucciones 5,000 tokens][Documentos 20,000 tokens][Pregunta C]
             └─ cambia ───┘
→ Aunque el resto coincide, no se puede reutilizar ni un solo token

La documentación de ambos proveedores indica que la caché no cambia el contenido de la salida. No guarda una respuesta anterior para repetirla; solo se ahorra el trabajo de leer la entrada. Por eso sigue siendo útil en chats donde cada pregunta es distinta o en agentes que leen documentos diferentes cada vez, siempre que haya un prefijo común (instrucciones, definiciones de herramientas, historial de conversación).

2. Prompt caching de OpenAI y de Anthropic, frente a frente

El 22 de septiembre de 2026, OpenAI anunció mejoras de la caché para GPT-6, y el mecanismo cambió para GPT-5.6 y los modelos posteriores (retención de 30 minutos, puntos de corte explícitos, escrituras de caché de pago, entre otros). La columna de OpenAI de la tabla describe GPT-5.6 y posteriores. Las diferencias de GPT-5.5 y anteriores se explican después de la tabla.

Fuentes: OpenAI "Prompt caching", "Prompt cache diagnostics"; Anthropic "Prompt caching", "Cache diagnostics", "Rate limits" (consultadas el 3 de octubre de 2026)

GPT-5.5 y los modelos anteriores solo tienen caché implícita, con puntos de corte colocados automáticamente a intervalos fijos, y sin recargo por escribir en caché. La retención se fija con prompt_cache_retention: según la guía, in_memory dura "unos 5 a 10 minutos de inactividad, hasta 1 hora", y 24h dura "normalmente unos 30 minutos, hasta 24 horas". Al pasar a GPT-5.6 o posterior, sustituye este ajuste por prompt_cache_options.ttl.

Los precios por token de cada modelo están en nuestra comparativa "Claude vs ChatGPT: comparativa de precios". Para los modelos GPT-6 (Astra, Sol, Luna), consulta "nuestro artículo sobre GPT-6 Sol y Luna", y para los modelos actuales de todos los proveedores, "Fechas de corte de conocimiento de la IA".

3. Cuándo acierta la caché: prefijo, longitud mínima, TTL y alcance

El prefijo común y el orden de la solicitud

En ambas plataformas, la caché acierta solo cuando el prefijo hasta el punto de corte coincide exactamente. Claude lee la solicitud desde el principio en el orden tools → system → messages, así que cambiar una sola definición de herramienta invalida la caché del prompt de sistema y del historial que vienen detrás. OpenAI explica igualmente que las definiciones de herramientas, el formato de salida (text.format), el esfuerzo de razonamiento (reasoning.effort) y ajustes similares forman parte del prefijo.

En la práctica, la disposición es la misma en ambas: primero lo que no cambia (definiciones de herramientas, instrucciones, documentos) y al final lo que cambia en cada solicitud (fechas, datos de cada usuario, la pregunta). Amplía la conversación añadiendo al final, sin reescribir el historial.

Colocar los puntos de corte: automático o manual

El modo implícito de OpenAI (GPT-5.6 y posteriores) coloca un punto de corte al final del mensaje elegible más reciente (un mensaje del usuario, el último de una serie de resultados de herramientas, etc.). En el modo solo explícito, únicamente las posiciones donde añadas prompt_cache_breakpoint son puntos de corte, y si no añades ninguno, no se usa la caché y tampoco pagas escrituras.

La caché automática de Claude, que se activa con un único "cache_control": {"type": "ephemeral"} en el nivel superior, coloca un punto de corte en el último bloque que se puede almacenar en caché y lo va desplazando a medida que crece la conversación. Si añades cache_control a bloques concretos, eliges tú los puntos de corte.

// Claude: punto de corte al final del prompt de sistema fijo (punto de corte explícito)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Instrucciones y documentos largos...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "La pregunta de hoy..." }]
}

// OpenAI (Responses API): punto de corte tras las instrucciones fijas, modo solo explícito
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Instrucciones y documentos largos...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "La pregunta de hoy..." }
  ]
}

Longitud mínima: los prefijos cortos no se guardan

Para GPT-5.6 y posteriores, el mínimo de OpenAI es de 1,024 tokens de entrada visible (las instrucciones ocultas que OpenAI añade internamente no cuentan). En Claude depende del modelo.

Fuente: Anthropic "Prompt caching", Cache limitations (consultada el 3 de octubre de 2026). En Bedrock se aplican los valores de la documentación de AWS.

Si un prompt de Claude no llega al mínimo, añadir cache_control no da error: el prompt simplemente no se guarda en caché, sin aviso. En ese caso, cache_creation_input_tokens y cache_read_input_tokens en usage valen 0. El mínimo cambia al cambiar de modelo, así que un prefijo que se guardaba con el modelo anterior puede dejar de guardarse (la guía de OpenAI hace la misma advertencia).

TTL: fíjate en cuándo empieza a contar

En OpenAI (GPT-5.6 y posteriores), la caché dura "al menos 30 minutos desde la última escritura o reutilización, y puede persistir más". Claude usa 5 minutos por defecto, y elegir 1 hora hace que la escritura cueste 2x el precio de entrada. En ambas plataformas, el TTL se renueva sin coste adicional cada vez que se usa la caché.

Claude tiene una trampa: el TTL se cuenta desde el inicio de la solicitud, no desde el final de la respuesta. En el ejemplo de la documentación, si una respuesta tarda 4 minutos en generarse, la siguiente solicitud tiene que empezar como mucho alrededor de 1 minuto después de terminar esa respuesta para acertar en la caché de 5 minutos. En agentes que generan salidas largas, 5 minutos es menos de lo que parece.

Alcance de la caché y dónde vive

La caché de OpenAI es por organización y no se comparte entre regiones de procesamiento (ajustes de residencia de datos). La guía también indica que la caché vive en máquinas concretas y que, por encima de unas 15 solicitudes por minuto, las solicitudes pueden enviarse a otra máquina. Desde GPT-5.6, OpenAI gestiona el enrutamiento automáticamente, y prompt_cache_key ha pasado a ser un ajuste opcional para separar los informes de caché por cliente más que una forma de subir la tasa de acierto (en GPT-5.5 y anteriores sí importaba usar la misma clave para dirigir las solicitudes a la misma máquina).

La API de Claude delimita la caché por espacio de trabajo. Dentro de una misma organización, espacios de trabajo distintos no comparten caché ni siquiera con prompts idénticos. En Bedrock y Google Cloud es por organización. Además, la caché solo está disponible cuando empieza la primera respuesta, así que si envías de golpe muchas solicitudes en paralelo con el mismo prefijo, las demás también se convierten en escrituras antes de que la primera haya escrito la caché.

4. Precio y punto de equilibrio: cuántas lecturas hacen falta para que compense

Como escribir en caché cuesta más que la entrada normal, una entrada de caché que se escribe y nunca se lee sale más cara que no usar caché. Sea w el multiplicador de escritura, r el de lectura y n el número de lecturas tras la escritura. El número de lecturas necesario para compensar sale de estas fórmulas.

Con caché     = w + n × r
Sin caché     = 1 + n          (enviar el mismo prefijo n + 1 veces tal cual)
Compensa si   : n > (w − 1) ÷ (1 − r)

Multiplicadores respecto a un precio de entrada de 1. Calculado a partir de OpenAI "Prompt caching" y "Pricing" y Anthropic "Pricing" (consultadas el 3 de octubre de 2026). Solo se compara el prefijo; se excluyen la salida y la pregunta de cada solicitud.

La guía de OpenAI incluye el mismo cálculo para un modelo de 0.1x: escribir una vez y leer una vez cuesta 1.35x, frente a 2x por procesarlo dos veces sin caché. La página de precios de Anthropic también dice que la caché de 5 minutos compensa tras una lectura y la de 1 hora tras dos. Por barata que sea la lectura, una caché de 1 hora no puede compensar con una sola lectura, porque la escritura a 2x pesa demasiado.

Modelos con el mismo precio de entrada: el intervalo entre solicitudes invierte el resultado

Con los precios oficiales a 3 de octubre de 2026, GPT-6.1 Sol y Claude Sonnet 5.5 cobran ambos $2 por millón de tokens de entrada, y su precio de escritura de 5 minutos es el mismo, $2.50. Lo que cambia es el precio de lectura (Sol $0.10, Sonnet 5.5 $0.20) y el TTL. Calculamos el coste del prefijo al enviar 10 veces un prefijo de 100,000 tokens con distintos intervalos.

Precios de OpenAI "Pricing" (Standard, hasta 272K) y Anthropic "Pricing" (ambas consultadas el 3 de octubre de 2026). 100,000 tokens = 0.1 (en unidades de 1 millón de tokens). Con aciertos, la primera solicitud es una escritura y las otras 9 son lecturas; con fallos, las 10 son escrituras. OpenAI también puede fallar por el enrutamiento entre máquinas y factores similares, así que las filas con aciertos son valores en condiciones favorables.

Por ejemplo, GPT-6.1 Sol cada 3 minutos sale a "0.1 × $2.50 (una escritura) + 0.1 × $0.10 × 9 lecturas = $0.25 + $0.09 = $0.34". La tabla muestra tres cosas.

• Con intervalos de 5 minutos o menos, la diferencia entre ambos es pequeña ($0.34 frente a $0.43). Depende solo del precio de lectura.
• Con intervalos de 5 a 30 minutos, gana el TTL de 30 minutos de OpenAI. Con el TTL de 5 minutos de Claude, cada solicitud se convierte en una escritura y cuesta $2.50, más que no usar caché. Pasar a 1 hora lo baja a $0.58.
• Cuando el intervalo supera el TTL, la caché hace perder dinero. Cada 2 horas, lo más barato es no usar caché, a $2.00. En Claude, no pongas cache_control; en OpenAI GPT-5.6 y posteriores, usa el modo solo explícito sin puntos de corte y te ahorras el cargo por escritura.

En particular, como la caché está activada por defecto en OpenAI GPT-5.6 y posteriores, quedarse en modo implícito puede suponer pagar la escritura incluso por entradas que nunca volverás a enviar. Si tu carga envía muchas entradas largas de un solo uso, revisa cache_write_tokens en usage y decide si te conviene pasar al modo solo explícito.

Cómo se combina la caché con otras tarifas

• Batch: la lista de precios de OpenAI también incluye precios de entrada en caché y de escritura en caché para Batch y Flex (GPT-6.1 Sol en Batch: $1 de entrada, $0.05 por lectura de caché, $1.25 por escritura). Anthropic indica que los multiplicadores de caché se acumulan con el 50% de descuento de batch, pero como las solicitudes por lotes se procesan en paralelo y sin un orden concreto, describe los aciertos de caché como "best effort" (sin garantía).
• Entradas largas: en OpenAI, cuando la entrada supera los 272K tokens, el precio de entrada, el de lectura y el de escritura de caché se duplican (los multiplicadores no cambian). En Anthropic, Claude 4.6 y los modelos posteriores cobran el mismo precio hasta 1 millón de tokens.
• Precalentamiento: en ambos, la escritura de precalentamiento se factura al precio normal de escritura. El max_tokens: 0 de Claude no genera cargo de salida.

5. Por qué no funciona el prompt caching: causas habituales

Si se combinan las notas de ambos proveedores sobre errores frecuentes con las listas de motivos que devuelven sus diagnósticos, las causas de los fallos de caché se agrupan en tres tipos.

Problemas habituales con OpenAI

• No hay punto de corte justo después del prefijo común: el modo implícito coloca el punto de corte al final del último mensaje, así que con "instrucciones fijas + un mensaje de usuario distinto cada vez" también se escribe la parte variable y la siguiente solicitud falla. Pon un punto de corte explícito justo después de la parte fija.
• Pasar al modo solo explícito a mitad de camino: el modo solo explícito solo busca los puntos de corte que tú colocaste, así que no acierta en entradas de caché escritas en modo implícito.
• Añadir contenido al mismo mensaje: si un mensaje que terminaba en "contenido A" pasa a ser "contenido A + contenido B", el punto de corte anterior queda en mitad de un mensaje y falla. Añade el contenido nuevo como un mensaje nuevo.
• Cambiar el esfuerzo de razonamiento a mitad de camino: en los modelos GPT-6 puedes cambiarlo sin romper la caché si dejas tal cual el reasoning.effort de la solicitud y añades un configuration_update después de la entrada.
• Ejecutar la compactación (compresión del contexto): el prefijo cambia, así que baja la tasa de acierto. Aun así, la guía señala que el coste total puede bajar porque la entrada se reduce, y recomienda comparar el coste total.

Problemas habituales con Claude

• Un punto de corte en un bloque que cambia cada vez: las escrituras solo ocurren en las posiciones de los puntos de corte, y las lecturas solo buscan hacia atrás posiciones de escritura anteriores. Si un punto de corte está en un bloque que cambia cada vez, pagas la escritura siempre y nunca aciertas. La caché automática también pone su punto de corte en el último bloque, así que cae en la misma trampa. Pon un punto de corte explícito en el último bloque que no cambia.
• 20 bloques o más añadidos en un turno: la búsqueda de escrituras anteriores abarca hasta 20 posiciones hacia atrás desde un punto de corte. Si la conversación crece mucho de golpe, la escritura anterior queda fuera de esa ventana. Mantén un punto de corte adicional más atrás en el prompt.
• Reescribir el prompt de sistema a mitad de camino: en los modelos compatibles, puedes añadir instrucciones sin romper la caché dejando intacto el system del nivel superior y añadiendo dentro de messages un mensaje con "role": "system".
• Alternar entre el modo rápido (speed: "fast") y el estándar: invalida las cachés del sistema y de la conversación.

6. Cómo comprobar los aciertos de caché: usage y diagnóstico

Empieza por usage: input_tokens significa cosas distintas

En ambas plataformas, el usage de la respuesta indica cuánto se leyó de la caché y cuánto se escribió en ella. Lo que hay que vigilar es que input_tokens significa cosas opuestas en las dos plataformas.

Fuentes: OpenAI "Prompt caching", Monitor cache performance; Anthropic "Prompt caching", Tracking cache performance (consultadas el 3 de octubre de 2026)

Si divides entre el input_tokens de Claude como si fuera la entrada total, tanto la tasa de acierto como el coste saldrán muy desviados. Cuando pongas las cifras de ambos proveedores en el mismo panel, normaliza los totales con las fórmulas de arriba antes de comparar. La guía de OpenAI recomienda calcular la "tasa de acierto por tokens" como el total de tokens leídos de la caché dividido entre el total de tokens de entrada, agregado por usuario, por día, etc.

Para el coste, en OpenAI es "(entrada − lecturas − escrituras) × precio + lecturas × precio × 0.1 + escrituras × precio × 1.25", y en Claude "input_tokens × precio + lecturas × precio × 0.1 + escrituras × precio × 1.25 (2 en la parte de 1 hora)" (sustituye el multiplicador de lectura por 0.05 u otro valor según el modelo). OpenAI tiene un "Prompt Caching Dashboard" en su página de uso, y la documentación de Rate limits de Anthropic remite a la página Usage para ver la tasa de acierto de caché.

Qué revisar, por orden, cuando las lecturas son 0

1. ¿Las escrituras también son 0? En Claude, si ambas son 0, el prompt no llega a la longitud mínima o falta cache_control. En OpenAI en modo solo explícito, tampoco hay escritura si no colocaste ningún punto de corte.
2. ¿Aparecen escrituras en cada solicitud? El punto de corte está en una posición que cambia cada vez, o algo del prefijo cambia cada vez. Usa el diagnóstico que se describe a continuación para encontrar qué cambió.
3. ¿Cuánto tiempo pasó desde la solicitud anterior? Comprueba si superó los 5 minutos de Claude (incluido el tiempo de generación de la respuesta) o los 30 minutos de OpenAI.

Diagnóstico de OpenAI: prompt_cache_diagnostics

En la Responses API de OpenAI, con los modelos compatibles de GPT-5.6 en adelante, si pasas el ID de una respuesta anterior en prompt_cache_options.comparison_response_id, el resultado de comparar esa solicitud con la actual aparece en prompt_cache_diagnostics. La documentación indica que no tiene coste adicional y que no cuenta aparte para los límites de uso.

// Añadir un objetivo de comparación a la segunda solicitud
{
  "model": "gpt-6.1-sol",
  "input": [ ...el mismo prefijo que la primera solicitud..., { "role": "user", "content": "Siguiente pregunta" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(ID de la primera respuesta)" }
}

// Ejemplo devuelto en un fallo (el ejemplo de la documentación: se renombró una herramienta)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

Hay cuatro valores de type: cache_hit, cache_miss, comparison_response_not_found (no hay registro de comparación o caducó) y unavailable (sin conclusión). En un fallo, reason es uno de estos nueve.

Fuente: OpenAI "Prompt cache diagnostics", Fix a cache miss (consultada el 3 de octubre de 2026)

Diagnóstico de Claude: diagnostics

En la API de Claude, tienes que incluir un campo diagnostics en todas las solicitudes, porque la API solo guarda una huella de comparación (hashes y recuentos estimados de tokens) de las solicitudes que lo llevan. En el primer turno, pasa "previous_message_id": null; a partir de ahí, pasa el id de la respuesta anterior.

// Del segundo turno en adelante
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(id de la respuesta anterior)" },
  "system": "...",
  "messages": [ ... ]
}

Si el diagnostics de la respuesta es null, no se encontró ninguna diferencia (o no se hizo la comparación); {"cache_miss_reason": null} significa que la comparación aún no ha terminado; y si aparece un motivo, señala el primer punto en el que las solicitudes divergen. Hay seis motivos: model_changed, system_changed, tools_changed, messages_changed, previous_message_not_found y unavailable. Los motivos *_changed vienen con cache_missed_input_tokens, una estimación de cuánto se perdió.

La documentación de Claude indica que el diagnóstico se lea junto con cache_read_input_tokens.

Fuente: Anthropic "Cache diagnostics", Reading diagnostics alongside usage (consultada el 3 de octubre de 2026)

Las dos funciones de diagnóstico tienen mucho en común: ambas devuelven solo la primera diferencia encontrada, así que, tras corregirla, hay que volver a comparar. Las diferencias son que el diagnóstico de Claude funciona solo en la API de Claude (no en Amazon Bedrock, Google Cloud, Claude Platform on AWS ni Microsoft Foundry) y solo compara con solicitudes del mismo espacio de trabajo. La documentación de OpenAI no describe ningún paso para marcar la solicitud anterior con la que se va a comparar. En Claude, si la solicitud anterior no incluía también diagnostics, obtienes previous_message_not_found.

7. Cifras de tasa de acierto: ejemplos de los proveedores y datos de terceros

Las cifras de tasa de acierto de caché que circulan significan cosas muy distintas según quién las publicó y en qué condiciones. Aquí van separadas.

Cifras de los proveedores

• Ejemplos de la guía de OpenAI: una carga de evaluación de un solo uso (un LLM como evaluador) con un punto de corte explícito tras una rúbrica fija alcanzó una "tasa de acierto por tokens de alrededor del 70%", y un agente que llama a herramientas repetidamente llegó a "más del 90%". La guía advierte que son ejemplos de resultados posibles y que el techo depende de la carga de trabajo.
• Comentarios de clientes en el anuncio de OpenAI (22 de septiembre de 2026): el equipo de Manus dice que, tras replantear la colocación de los puntos de corte, su tasa de acierto con modelos de OpenAI pasó de "alrededor del 85% a más del 90% de forma constante" en menos de una semana. Un comentario sobre GitHub Copilot dice que en los últimos meses ha reducido en más de un 50% la proporción de entrada que hay que volver a procesar respecto a su referencia anterior. Ambos son citas de clientes que OpenAI publicó en su propia página, no mediciones independientes.
• Anthropic: la documentación no da cifras reales de tasa de acierto. La página de Rate limits incluye un ejemplo, "con una tasa de acierto del 80%, un límite de entrada de 2 millones de tokens por minuto procesa en la práctica 10 millones de tokens por minuto", pero es una cuenta sobre un supuesto, no una medición.

Datos de terceros: no sirven como veredicto directo sobre cuál es mejor

Requesty, un servicio que enruta solicitudes a varias API de IA, agregó las solicitudes que pasaron por su propia pasarela y publicó tasas de acierto de abril de 2026 del 77% para Anthropic directo (77.50% en la tabla) y del 36% para OpenAI (36.40%) ("Prompt-cache hit rate per provider, April 2026", actualizado el 9 de mayo). A primera vista, Claude parece acertar más del doble de veces, pero hay cuatro motivos por los que estas cifras no sirven para la comparación de este artículo.

1. Los datos son anteriores al cambio de OpenAI: OpenAI introdujo la retención de 30 minutos y los puntos de corte explícitos el 22 de septiembre, y los datos de abril son de antes.
2. Las cargas de trabajo son distintas: son los resultados de aplicaciones de distintos usuarios que envían prompts diferentes a intervalos diferentes a través de la pasarela, no el mismo prompt enviado a ambos proveedores. En Claude solo cuentan las solicitudes en las que los usuarios añadieron cache_control por su cuenta.
3. El denominador: la página dice "cached_tokens ÷ input_tokens", pero, como se explica en la sección 6, el input_tokens de Claude excluye los tokens en caché. La página no dice cómo los convirtió.
4. La página se contradice: en un sitio sitúa a Claude vía Google Cloud (Vertex) en el 24% y en otro en el 14%.

En nuestra búsqueda del 3 de octubre de 2026 no encontramos ninguna medición de terceros que comparara las dos cachés en las mismas condiciones. Al final, la única forma de saber si la caché funciona en tu aplicación es medirla con tus propios datos de uso. Calcula la tasa de acierto y el coste con las fórmulas de la sección 6 y, si fallas, usa el diagnóstico para averiguar por qué.

Resumen

El prompt caching de OpenAI y el de Claude comparten la misma idea básica: reutilizar el prefijo idéntico y cobrar las lecturas a alrededor de 0.1x el precio de entrada. La diferencia es que OpenAI (GPT-5.6 y posteriores) está activado por defecto, mantiene la caché al menos 30 minutos y cobra 1.25x por escribir, mientras que Claude solo usa la caché si añades cache_control, la mantiene 5 minutos (con opción de 1 hora) y cobra 1.25x por escribir (2x con 1 hora).

En precio, como escribir cuesta más, una caché que nunca se lee sale a pérdida. Las cachés de 5 y 30 minutos compensan tras una lectura, y la de 1 hora de Claude tras dos. Con intervalos de 5 a 30 minutos entre solicitudes, el TTL de 30 minutos de OpenAI tiene ventaja, y en Claude elegir 1 hora evita la inversión. Si tus solicitudes están más separadas que el TTL, sale más barato no usar caché.

Comprueba si la caché funciona mirando las cantidades de lectura y escritura en usage. El input_tokens de Claude solo cubre lo que va después del punto de corte, así que calcula primero el total y luego la tasa de acierto. Cuando falla, el prompt_cache_diagnostics de OpenAI y el diagnostics de Claude te dicen en qué difiere la solicitud de la anterior. Para otras formas de reducir costes, consulta "Cómo ahorrar en gasto y tokens de IA".

Preguntas frecuentes

P. ¿Cuál es el TTL del prompt caching de OpenAI?

R. En GPT-5.6 y posteriores, al menos 30 minutos desde la última escritura o reutilización. El ajuste prompt_cache_options.ttl solo acepta "30m", y la guía indica que la caché puede durar más. En GPT-5.5 y anteriores se elige con prompt_cache_retention: in_memory dura unos 5 a 10 minutos de inactividad (hasta 1 hora) y 24h dura hasta 24 horas.

P. ¿Puedo alargar el TTL del prompt caching de Claude?

R. Sí, "cache_control": {"type": "ephemeral", "ttl": "1h"} te da 1 hora. La escritura cuesta 2x el precio de entrada, así que no compensa a menos que la caché se lea al menos dos veces. Si la sigues usando a intervalos de menos de 5 minutos, la caché de 5 minutos se renueva gratis con cada lectura. Ambos se cuentan desde el inicio de la solicitud, así que el tiempo que tarda en generarse una respuesta larga cuenta para el TTL.

P. ¿La caché cambia las respuestas?

R. No. La documentación de ambos proveedores dice que la caché no afecta a la generación de la salida. Lo que se guarda es el cálculo intermedio de leer la entrada, no la respuesta en sí. Igual que sin caché, la misma entrada no siempre produce la misma respuesta.

P. ¿Puedo borrar la caché manualmente?

R. Ninguna de las dos plataformas lo permite. OpenAI dice que las entradas caducan según el TTL y los ajustes, y Anthropic dice que se eliminan automáticamente tras al menos 5 minutos sin uso (1 hora si elegiste 1 hora). Si quieres sustituir el contenido del prompt, cambia el prefijo y la siguiente solicitud escribirá una entrada nueva.

Fuentes

• Documentación de la API de OpenAI: Prompt caching
• Documentación de la API de OpenAI: Prompt cache diagnostics
• Documentación de la API de OpenAI: Pricing
• OpenAI: Better prompt caching for GPT-6 (22 de septiembre de 2026)
• Documentación de Claude Platform: Prompt caching
• Documentación de Claude Platform: Cache diagnostics
• Documentación de Claude Platform: Pricing
• Documentación de Claude Platform: Rate limits
• Requesty: Prompt-cache hit rate per provider, April 2026

Todas las fuentes se comprobaron en su versión original el 3 de octubre de 2026. Los precios, los TTL y las longitudes mínimas pueden cambiar a medida que se añaden modelos, así que confírmalos en la página de precios de cada proveedor antes de basarte en ellos. Los cálculos de coste de este artículo son aritmética a partir de los precios oficiales, no mediciones hechas llamando nosotros mismos a las API.