Llevas todo el día hablando con un modelo de IA. Probablemente haya leído el mismo prompt de sistema, el mismo manual de producto y la misma definición de herramientas decenas de veces. ¿Eso significa que has quemado tokens decenas de veces? Aquí está el mecanismo más importante de los modelos modernos: la entrada que se repite no necesita volver a calcularse. Si lo configuras bien, tu factura puede caer hasta un 90%.
Abres una página web. La primera vez tarda. La segunda vez carga en un segundo. La razón es simple: el navegador guardó las imágenes, los scripts y los estilos en una caché local, y la próxima vez no necesita pedirlos al servidor.
El caché de los modelos de lenguaje funciona con la misma lógica, pero con una diferencia importante. Mientras la caché del navegador guarda archivos, la del LLM guarda el «estado de cálculo» que el modelo dejó después de leer la primera parte de tu input. Más exactamente: muchos proveedores guardan los resultados intermedios de las matrices key y value de las capas de atención. Por eso en la industria se le llama KV cache.
Este mecanismo permite que, cuando el modelo ya ha leído un bloque grande de contenido fijo, la siguiente vez que vea el mismo inicio pueda saltarse buena parte del trabajo.
Cuando el modelo recibe tu pregunta, pasa por dos fases bien diferenciadas.
La primera se llama prefill. Puedes pensar en ella como «leer todo lo que le pasaste». El modelo escanea tu prompt de sistema, el historial de la conversación, los documentos adjuntos y las definiciones de herramientas, y calcula las relaciones entre todos esos tokens. Cuanto más largo es el input, más caro es este paso.
La segunda se llama decode. Es «escribir hacia fuera». Apoyándose en el estado calculado por el prefill, el modelo genera la respuesta token por token.
El insight clave: en aplicaciones con input largo y respuesta corta, casi todo el coste se va antes de que el modelo abra la boca. Casos típicos: bots de atención al cliente, RAG, análisis de bases de código, agentes con muchas herramientas. En estos escenarios, el bloque fijo puede ocupar entre miles y cientos de miles de tokens, mientras que la pregunta nueva del usuario son dos líneas.
El prompt caching ataca exactamente esa primera mitad. La primera petición lee el contenido fijo y lo guarda en caché. La segunda petición, si comparte el mismo inicio, reutiliza ese estado y solo procesa lo que ha cambiado.
Importante: el caché no hace que el modelo «recuerde la respuesta», ni te ahorra tokens de salida. Solo te ahorra el coste de releer la entrada repetida.
Esta es la parte más contraintuitiva del prompt caching:
El sistema mira si el prefijo es exactamente igual byte por byte, no si el significado es parecido.
Compara estas dos peticiones:
Eres un asistente de cocina. Dime qué cenar.
Eres un asistente de cocina. Dime qué comer.La primera mitad es idéntica. El modelo tiene la oportunidad de reutilizar el bloque «Eres un asistente de cocina.».
Ahora compara estas otras dos:
¿Qué cenar? Eres un asistente de cocina.
¿Qué comer? Eres un asistente de cocina.La primera palabra ya es distinta. Aunque el rol del asistente sea exactamente el mismo, el caché casi nunca va a acertar.
Lo mismo pasa con JSON. Cambiar el orden de los campos, los saltos de línea o los espacios produce, desde el punto de vista del modelo, una entrada distinta. El sistema no entiende «más o menos lo mismo»: solo entiende «exactamente igual».
De ahí sale la regla más importante de todo este artículo:
Lo que no cambia, va al principio. Lo que cambia, va al final.
Si estás construyendo una aplicación con LLMs, este es el orden recomendado al ensamblar tu prompt:
Un fallo clásico que se ve en producción: alguien escribe en la primera línea del system prompt:
Ahora son las 15:30 del 4 de mayo de 2026.
Un minuto después se convierte en 15:31. Todo el prefijo cambia. Los miles de tokens que venían detrás se quedan sin caché.
La idea de fondo es la misma en todos. Las diferencias están en cómo se activa, el umbral mínimo y cuánto dura. Esta tabla resume el estado en mayo de 2026:
| Proveedor | Cómo se activa | Umbral mínimo | Ahorro al acertar | Tiempo de retención |
|---|---|---|---|---|
| OpenAI | Automático | 1024 tokens, sube de 128 en 128 | ~10% del precio base en GPT-5; algo más en modelos antiguos | 5–10 min sin actividad; 24 h opcional en algunos modelos |
| Claude | Manual: añadir cache_control en bloques reutilizables | 1024 o 2048 tokens según modelo | Lectura ~10% del precio de input; escritura ligeramente más cara | 5 min por defecto; 1 h opcional |
| Gemini | Implícito automático; explícito manual | Flash: 1024 · Pro: 4096 | Implícito: ahorro automático. Explícito: precio según plataforma | Explícito: 1 h por defecto, TTL configurable |
| DeepSeek | Automático | Reglas de prefijo internas, sin configuración manual | Precio de hit notablemente menor que el de miss; facturación separada | Caché en disco, best-effort, horas a días |
OpenAI es el más cómodo. No tienes que tocar el código: basta con que tu prompt supere el umbral y mantenga el mismo prefijo. Lo que tienes que mirar en la respuesta es el campo cached_tokens.
En Claude Code no necesitas preocuparte: la herramienta gestiona el caché por ti. Pero si llamas a la API de Claude directamente, tienes que añadir cache_control en los bloques de herramientas, system o mensajes para marcar dónde acaba el contenido reutilizable. El sistema busca, hacia atrás desde ese punto, el prefijo más largo que pueda reutilizar. Tienes más control, pero requiere diseño cuidadoso. Los campos a vigilar son cache_creation_input_tokens y cache_read_input_tokens.
Gemini ofrece dos modos. El caché implícito funciona como el de OpenAI: automático. El caché explícito es distinto: tú creas un objeto de caché con un bloque grande de material y luego lo referencias en cada llamada. Es ideal para «un material, muchas preguntas», pero el almacenamiento tiene coste.
DeepSeek destaca por usar caché en disco activado por defecto. No hace falta cambiar la interfaz. La respuesta incluye prompt_cache_hit_tokens y prompt_cache_miss_tokens. Es best-effort: no garantiza acertar siempre, y construir la caché tarda un poco la primera vez.
Imagina que estás construyendo un bot de atención al cliente. Cada petición incluye 5.000 tokens fijos entre system prompt y manual de producto. La pregunta media del usuario son 200 tokens. La respuesta media son 300 tokens. Procesas 10.000 peticiones al día.
Sin caché, los tokens de input son:
(5.000 + 200) × 10.000 = 52 millones de tokens al díaCon un precio normal de input de 2,50 USD por millón de tokens y output de 15 USD por millón:
Con caché activado, supongamos que de los 5.000 tokens fijos, 4.500 aciertan caché. El precio del caché es aproximadamente el 10% del precio normal:
Hits de caché: 4.500 × 10.000 = 45 millones de tokens
Input a precio completo: (500 + 200) × 10.000 = 7 millones
Output: 300 × 10.000 = 3 millonesAhorro diario: aproximadamente 100 USD. Casi la mitad de la factura, sin tocar la calidad de la respuesta.
La regla de fondo no cambia: cuanto más largo el input, más alta la repetición y más corta la respuesta, más vale el caché. Si tu modelo escribe textos largos a partir de un input pequeño, el ahorro relativo es mucho menor, porque el output sigue costando lo mismo.
El prompt caching mira los caracteres exactos. Un signo de puntuación distinto rompe la coincidencia. El caché semántico juega un partido diferente: compara significados.
Imagina que el usuario A pregunta:
¿Cuál es vuestra política de devoluciones?Y el usuario B pregunta:
Compré algo por error, ¿cómo lo devuelvo?El caché semántico evalúa si las dos preguntas tratan del mismo tema. Si la similitud es lo bastante alta, devuelve la respuesta anterior sin volver a llamar al modelo.
Esto se implementa en la capa de aplicación, no en el modelo. La forma habitual: meter las preguntas y respuestas históricas en una base de datos vectorial; cuando llega una pregunta nueva, buscar las más parecidas; si la similitud supera un umbral, devolver la respuesta cacheada.
Los dos cachés se combinan bien:
Pero el caché semántico tiene un riesgo serio. Parecido no es igual. En contextos como devoluciones, contratos, salud o finanzas, una falsa coincidencia destruye la confianza del usuario. El umbral debe ser muy conservador, y para preguntas críticas conviene siempre dejar que el modelo responda de cero.
Cualquier variable que cambia en cada petición rompe el caché si se sitúa al inicio. Es un fallo silencioso: la factura sube y nadie sabe por qué.
La misma configuración con otro orden de campos es, para el modelo, otro input distinto. Asegúrate de serializar siempre con orden fijo y la misma indentación.
Algo como «Estás atendiendo a Juan, le gustan respuestas cortas» al principio significa que cada usuario genera su propio prefijo único. Mejor: deja las reglas globales arriba y mete el perfil del usuario al final.
Cada proveedor lo expone con un nombre distinto: OpenAI usa cached_tokens, Claude usa cache_read_input_tokens, Gemini lo entrega dentro de usage_metadata, DeepSeek usa prompt_cache_hit_tokens. Sin mirar estos campos no sabes si tu caché está funcionando.
El prompt caching no hace al modelo más listo ni a las respuestas más estables. Solo reutiliza el cálculo del prefijo. La salida sigue generándose en el momento, y la temperatura, el sampling y el contexto siguen influyendo igual.
Esta es la parte que más gente se salta. Sin verificar, no sabes si lo que crees que ahorras es real:
Lo que no cambia, va al principio. Lo que cambia, va al final.
Si haces bien esta única cosa, el caché de los modelos de lenguaje tiene la oportunidad de ahorrarte hasta el 90% de la factura de input. No te hace más inteligente, no cambia la calidad de la respuesta, y no es magia. Es solo evitar que el modelo vuelva a hacer trabajo que ya hizo antes.
En aplicaciones reales —agentes, RAG, atención al cliente, asistentes— ese ahorro suele ser la diferencia entre un producto rentable y uno que no escala. Vale el rato que cuesta hacerlo bien.
Si estás creando un agente con Claude Code, no necesitas configurar el caché manualmente: la propia herramienta lo gestiona por ti. Pero conocer cómo funciona te ayuda a estructurar tus prompts y proyectos para que el ahorro sea real.
Ver la guía completa de Claude Code