≡En resumen
- La caché de prompts reutiliza el procesamiento de un prefijo que se repite entre peticiones.
- Escribir en caché cuesta algo más que la entrada normal; leer de ella cuesta una pequeña fracción.
- La caché dura 5 minutos por defecto, se renueva con cada uso y puede ampliarse a 1 hora.
- Cualquier cambio en herramientas, sistema o mensajes anteriores al punto de corte invalida la caché.
- Claude Code y muchos agentes la aprovechan para no pagar una y otra vez por el mismo contexto.
01 ¿Qué es el prompt caching?
En una aplicación con IA, gran parte de cada petición se repite: el mismo prompt de sistema, las mismas definiciones de herramientas, el mismo documento de referencia y todo el historial de la conversación hasta el último mensaje. Sin caché, el modelo procesa ese texto completo en cada llamada y lo cobras como entrada cada vez.
El prompt caching permite que la API de Claude guarde el resultado de procesar ese prefijo. Cuando llega otra petición que empieza exactamente igual, la API reanuda desde el punto guardado. La salida del modelo no cambia: solo se ahorra trabajo repetido en la entrada.
02 Cómo funciona la caché de prompts de Claude
La caché trabaja sobre el prefijo de la petición, que se ordena siempre así: herramientas, prompt de sistema y mensajes. Un punto de corte (cache_control) marca hasta dónde se guarda. Hay dos formas de activarlo.
-
1
Caché automática
Añades un único campo cache_control en la raíz de la petición. La API coloca el punto de corte en el último bloque que se puede guardar y lo va moviendo según crece la conversación.
-
2
Puntos de corte explícitos
Pones cache_control en bloques concretos (por ejemplo, al final del prompt de sistema y al final de un documento). Puedes usar hasta 4 por petición.
-
3
Primera petición: escritura
Si no hay caché, la API procesa todo y guarda el prefijo en cuanto empieza la respuesta. Esos tokens aparecen en cache_creation_input_tokens.
-
4
Siguientes peticiones: lectura
Si el prefijo es idéntico, la API lo lee de la caché. Esos tokens aparecen en cache_read_input_tokens; lo que va después del punto de corte se cobra como entrada normal.
-
5
Búsqueda hacia atrás
Para encontrar entradas guardadas por peticiones anteriores, la API revisa hasta 20 bloques hacia atrás desde el punto de corte.
03 Cuánto dura la caché y cómo cambia el coste
El ahorro viene de la diferencia entre escribir y leer. Escribir en la caché cuesta un poco más que la entrada normal; leer de ella cuesta una pequeña fracción. Las cifras exactas varían por modelo y cambian con el tiempo, así que consulta siempre la página oficial de precios; esta tabla resume la estructura en octubre de 2026.
| Concepto | Cómo funciona | Coste relativo a la entrada normal |
|---|---|---|
| Caché de 5 minutos | Opción por defecto; cada uso renueva el plazo sin coste | Escritura algo más cara (1,25 veces) |
| Caché de 1 hora | Se pide con ttl de 1h; útil si las peticiones están más espaciadas | Escritura más cara (2 veces) |
| Lectura de caché | Cada acierto sobre un prefijo guardado | Una fracción: 0,1 veces en la mayoría de modelos y menos en algunos de los más recientes |
| Tokens tras el punto de corte | La parte nueva de cada petición | Precio normal de entrada |
04 Requisitos: longitud mínima y prefijos idénticos
Para que haya caché, el prefijo tiene que superar una longitud mínima en tokens. Si es más corto, la petición se procesa sin caché y sin error, así que conviene revisar los campos de uso de la respuesta para confirmar que funciona.
Longitud mínima
Va de 512 a 4.096 tokens según el modelo. En los modelos más recientes de la familia Claude 5, como Opus 5.5, Sonnet 5.5 y Haiku 5.5, es de 512.
Coincidencia exacta
El prefijo debe ser idéntico al 100 %: un espacio, un dato o un orden distinto ya es otra caché.
Aislamiento
Las cachés están aisladas por organización y, en la API de Claude, también por espacio de trabajo.
Peticiones en paralelo
Una entrada de caché solo está disponible cuando empieza la primera respuesta; espera a ella antes de lanzar peticiones paralelas que la necesiten.
05 Qué invalida la caché de prompts
Como el prefijo se construye en orden (herramientas, sistema, mensajes), un cambio en un nivel invalida ese nivel y todos los siguientes.
| Cambio | Qué se invalida |
|---|---|
| Añadir, quitar o modificar herramientas | Herramientas, sistema y mensajes: todo |
| Modificar el prompt de sistema | Sistema y mensajes |
| Activar o desactivar búsqueda web o citas | Sistema y mensajes |
| Cambiar tool_choice, imágenes, configuración de razonamiento o nivel de esfuerzo | Mensajes |
| Cambiar de modelo | Todo: cada modelo tiene su propia caché |
| Reescribir el historial (por ejemplo, al compactar) | Todo lo que va desde el punto modificado |
Por eso la compactación de contexto encarece un poco la petición siguiente: el historial cambia y hay que volver a escribir la caché.
06 Cuándo usar prompt caching: casos de uso
Chatbots con instrucciones largas
El prompt de sistema, las políticas y las herramientas se repiten en cada mensaje: candidatos perfectos para la caché.
Preguntas sobre documentos
Contratos, manuales o informes que se consultan varias veces seguidas.
Agentes de programación
Cada turno reenvía todo el historial; la caché evita volver a procesar los turnos anteriores.
Muchos ejemplos en el prompt
Prompts con decenas de ejemplos para clasificar o extraer datos con un formato fijo.
Un chatbot con IA para empresas usa un prompt de sistema con la política de envíos, devoluciones y tono de marca, más cinco herramientas. Todo eso se coloca antes del punto de corte. Mientras haya conversaciones activas, cada mensaje nuevo solo paga a precio normal lo que el cliente acaba de escribir; el resto se lee de la caché. En la respuesta, los campos cache_read_input_tokens y cache_creation_input_tokens permiten comprobar el ahorro.
07 La caché en Claude Code y en tus propios productos
Claude Code aplica la caché de prompts de forma automática, y algunas de sus decisiones de diseño se explican por ella. Por ejemplo, su documentación sobre tareas programadas indica que un bucle con /loop cada cinco minutos se adelanta unos segundos precisamente para no llegar justo después de que caduque la caché de cinco minutos. Del mismo modo, cambiar de modelo a mitad de sesión obliga a empezar una caché nueva.
Si desarrollas un producto propio sobre la API de Claude, diseñar el orden del prompt pensando en la caché es una de las optimizaciones con mejor relación esfuerzo-ahorro. Lo aplicamos de serie en cualquier desarrollo de SaaS que integre IA, junto con la ingeniería de contexto.
- ✓Pon lo estable al principio (herramientas, sistema, documentos) y lo variable al final.
- ✓No metas fechas, identificadores aleatorios ni datos del usuario antes del punto de corte.
- ✓Mantén las herramientas en el mismo orden en todas las peticiones.
- ✓Usa la caché de 1 hora si entre peticiones pasan más de 5 minutos.
- ✓Comprueba en cada respuesta los campos de lectura y escritura de caché.
Para más utilidades que ayudan a reducir el consumo de tokens con Claude, consulta el hub de recursos de IA.
Preguntas frecuentes sobre Prompt caching (caché de prompts)
Es una función de la API de Claude que guarda el procesamiento del prefijo de una petición para reutilizarlo en peticiones posteriores que empiecen igual, reduciendo coste y latencia.
5 minutos por defecto, y el plazo se renueva sin coste cada vez que se usa. Puedes pedir una caché de 1 hora, cuya escritura cuesta más.
Leer de la caché cuesta una pequeña fracción del precio normal de entrada, en torno a una décima parte o menos según el modelo, mientras que escribir cuesta algo más. El ahorro real depende de cuántas veces reutilices el mismo prefijo.
Las causas habituales son un prefijo más corto que el mínimo del modelo, un dato que cambia antes del punto de corte, herramientas en distinto orden o peticiones separadas por más tiempo que la vida de la caché.
Hasta 4 por petición. Si combinas la caché automática con puntos explícitos, la automática ocupa uno de esos 4.
Sí, lo aplica de forma automática. Por eso conviene no cambiar de modelo ni de configuración a mitad de una sesión si no es necesario.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗