Cada request envía el mismo system prompt de 10,000 tokens. Los mismos estándares de código. Los mismos ejemplos few-shot. Las mismas definiciones de herramientas. Pagas el precio completo de entrada por cada uno. Con 500 requests al día en GPT-5.5 a $5/M de entrada, eso es $25 al día —$750 al mes— solo por contenido que el modelo ya procesó 500 veces.
El prompt caching reduce eso a $75 al mes. Mismo contenido. Misma calidad de salida. Un cambio de código. El prompt caching es una de las 12 estrategias cubiertas en nuestro recorrido de optimización de costos —y entrega la ROI más alta con el cambio de código más pequeño.
Este artículo cubre cómo funciona el caching en los cuatro grandes proveedores, el código exacto para implementarlo y cómo diagnosticar si tu carga es amigable con el caché. Esta es la referencia autoritativa del prompt caching en todo el blog de TokSpan —otros artículos enlazan aquí para los detalles completos de implementación.
Cómo funciona el prompt caching (y por qué no es una bala de plata)
Cuando envías un prompt a un LLM, el modelo procesa cada token —incluso los que ya vio cientos de veces. El cómputo se repite en cada request. Cachea esos tokens y el modelo omite el cómputo redundante.
La mecánica: marcas una parte de tu prompt como cacheable. El proveedor hace hash de esa parte. En requests posteriores con el mismo prefijo, el proveedor recupera el cómputo cacheado en lugar de volver a ejecutarlo. Pagas una tarifa reducida por tokens cacheados —o, con algunos proveedores, ningún costo de inferencia por la parte cacheada.
Qué se puede cachear: system prompts (el caso más común y de mayor ROI). Definiciones de herramientas —son idénticas entre requests. Ejemplos few-shot. Contexto estático de documentos —documentación de producto, artículos de base de conocimiento, estándares de código. Historial de conversación hasta el último mensaje —el historial es idéntico hasta el mensaje de usuario más reciente.
Qué no se puede cachear: el mensaje nuevo del usuario —está al final del prompt y es único por request. Prefijos no deterministas —cualquier cosa que cambie entre requests. Contenido más corto que la longitud mínima de caché del proveedor (típicamente 1,024 tokens).
La contra: los cachés expiran. Los TTL van de 5 minutos (Anthropic, OpenAI) a horas configurables (Google). Si tu intervalo de requests excede el TTL, el caché está frío y pagas el precio completo. Los cachés también son específicos del proveedor y del modelo —cambiar de Opus a Sonnet invalida el caché.
Implementación por proveedor
Anthropic —90% de descuento, mejor de su clase, control explícito.
Anthropic ofrece la mejor economía de caching de la industria: 90% de descuento en tokens de entrada cacheados. La documentación de prompt caching de Anthropic cubre los puntos de ruptura de caché, el comportamiento del TTL y los precios en detalle. Las escrituras de caché conllevan un pequeño premium sobre el precio base de entrada (ver desglose de precios abajo). Punto de equilibrio: aproximadamente 1.3 requests totales por escritura de caché —es decir, solo 2 requests que compartan un prefijo cacheado ya ahorran ~32.5%. Para la mayoría de las cargas de producción, tendrás docenas. Para un recorrido completo de configurar el SDK de Anthropic con caching, consulta nuestra guía de desarrollo de la API de Claude.
import anthropic
client = anthropic.Anthropic(
base_url="https://api.tokspan.com/anthropic",
api_key="ts-your-key-here"
)
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1000,
system=[
{
"type": "text",
"text": "You are a code reviewer. Here are our 10,000-token coding standards...",
"cache_control": {"type": "ephemeral"} # Cache this
}
],
messages=[{"role": "user", "content": "Review this PR."}]
)Puntos de ruptura de caché. Puedes colocar múltiples bloques cache_control a lo largo de tus mensajes. Cada uno marca un punto donde el prefijo hasta ese punto se cachea. Ubicación estratégica: cachea el system prompt (siempre). Cachea el historial de conversación excluyendo el último mensaje del usuario (el historial es estático; el nuevo mensaje del usuario es dinámico). Cachea las definiciones de herramientas (rara vez cambian).
Longitud mínima cacheable: 4,096 tokens para Opus 4.5+ (incluyendo Opus 4.8/4.7/4.6/4.5) y Haiku 4.5; 2,048 tokens para Sonnet 4.6. Los prompts más cortos que esto no se cachearán —la sobrecarga de gestionar el caché excede el ahorro de cómputo.
OpenAI —50% de descuento, automático, cero esfuerzo.
El prompt caching de OpenAI es automático para prompts de más de 1,024 tokens. Sin cambios de código. Sin bloques cache_control. El proveedor detecta prefijos repetidos y aplica el descuento silenciosamente. El trade-off: 50% de descuento vs. el 90% de Anthropic, y sin garantía de cache hit —el proveedor decide cuándo cachear.
# No special code needed. OpenAI automatically caches repeated prefixes.
response = client.chat.completions.create(
model="gpt-5.5",
messages=[
{"role": "system", "content": "Your 5,000-token system prompt here..."},
{"role": "user", "content": "User message here."}
]
)
# If the system prompt was cached, you pay 50% less for those input tokens.
# Check response.usage for cache status.Google Gemini —context caching, explícito, TTL configurable.
El enfoque de Google es diferente: creas un recurso de “contenido cacheado” con un TTL explícito —los docs de context caching de Google cubren configuración y precios. Los TTL van de minutos a 24 horas. Haces referencia al contenido cacheado en tus requests. El caché persiste entre múltiples requests y usuarios. Mejor para: Q&A de documentos con contenido estático que múltiples usuarios consultan.
DeepSeek —$0.0036/M por cache hit, automático, precio absoluto más barato.
El precio de cache hit de DeepSeek de $0.0036 por millón de tokens es absurdamente barato —40x más barato que su ya barata tarifa base. El caching es automático (similar a OpenAI). Sin control explícito. Pero a este precio, la economía es favorable para prácticamente cualquier carga con contenido repetido.
Precios de caché: el ahorro real
| Proveedor | Escritura de caché | Lectura de caché | vs. Entrada base | TTL | ¿Automático? |
|---|---|---|---|---|---|
| Anthropic | 1.25x base | 10% de la base | 90% de descuento | ~5 min | No (explícito) |
| OpenAI | — | 50% de la base | 50% de descuento | 5–60 min | Sí |
| Google Gemini | Varía según el TTL | Varía según el TTL | Hasta 75% de descuento | Configurable | No (explícito) |
| DeepSeek | — | $0.0036/M | ~97% de descuento | ~5 min | Sí |
Guía de selección. Más allá del precio bruto, la implementación de caching de cada proveedor tiene compensaciones arquitectónicas. Anthropic te da control explícito y el descuento más profundo —pero pagas un premium del 25% por escritura de caché y debes gestionar la ubicación de los puntos de ruptura tú mismo. OpenAI es de “dispara y olvida”: cero código, 50% de ahorro, sin garantía de hits. El TTL configurable de Google es único: pon un caché de 24 horas en tu documentación de producto y sirve a miles de usuarios contra un solo recurso cacheado. El piso de precio absoluto de DeepSeek ($0.0036 por millón de tokens cacheados) hace que la optimización de la tasa de hits sea en gran parte irrelevante —a ese precio, incluso una tasa de hits del 10% ahorra dinero.
| Proveedor | Longitud mínima de caché | Esfuerzo | Mejor para | Advertencia |
|---|---|---|---|---|
| Anthropic | 4,096 tokens (Opus 4.5+, Haiku 4.5); 2,048 (Sonnet 4.6) | Añade 3 líneas | System prompts, definiciones de herramientas, few-shot | Costo de escritura 1.25x; TTL de 5 min |
| OpenAI | 1,024 tokens | Ninguno | Cualquier carga, ahorro automático | Sin garantía de hits; solo 50% de descuento |
| Google Gemini | Varía según el modelo | Crear un recurso | Q&A de documentos, necesidades de TTL largo | Mayor costo para TTL más largos |
| DeepSeek | ~1,024 tokens | Ninguno | Alto volumen, sensible al precio | Solo automático; menos predecible |
Calculadora de ahorro. Una carga con 500 requests/día, system prompt cacheado de 10,000 tokens, mensajes de usuario de 500 tokens, usando Claude Opus a $5/M de entrada:
- Sin caching: 500 × (10,000/1,000,000 × $5) = $25/día solo en contenido cacheable
- Con caching: 500 × (10,000/1,000,000 × $0.50) = $2.50/día en contenido cacheable
- Ahorro anual: $8,212 —$821 en ese contenido. Un cambio de código.
El costo oculto de escritura de caché. Anthropic cobra 1.25x el precio base de entrada por escrituras de caché. El punto de equilibrio es aproximadamente 1.3 requests totales por escritura —es decir, incluso una sola lectura de caché (2 requests compartiendo el mismo prompt) ahorra ~32.5% vs. sin caching. Para system prompts y definiciones de herramientas que son idénticas en todos los requests, esto nunca es una preocupación. Para contenido donde la mayoría de los requests son únicos (sin lecturas de caché), pagas el premium del 25% por escritura con cero ahorro compensatorio. Monitorea tu tasa de cache hit. Apunta a >80%.
¿Es tu carga amigable con el caché?
Mejores cargas para caching:
- Chatbots con system prompts largos —el prompt es idéntico entre todos los usuarios y conversaciones. Tasa de hits: cerca del 100%.
- Aplicaciones RAG con contexto estático de documentos —el contenido de la base de conocimiento es el mismo para cada consulta. Tasa de hits: alta, dependiendo de cuántos documentos distintos consultes.
- Tareas con prompts few-shot —tus ejemplos son idénticos entre requests. Cachéalos.
- Conversaciones de múltiples turnos con historial largo —el historial hasta el último mensaje es estático. Cachea todo excepto el turno final del usuario.
- Agentes de código con definiciones de herramientas —los esquemas de herramientas son estáticos. Cachéalos.
Peores cargas para caching:
- Prompts de una sola vez —cada request es único. Sin prefijos repetidos. Tasa de hits: 0%.
- Documentos únicos por request —si cada consulta es contra un documento diferente, no hay nada que cachear.
- Prompts muy cortos (<1,024 tokens) —por debajo de la longitud mínima cacheable para la mayoría de los proveedores.
- Generación de alta aleatoriedad —si cada respuesta es creativa y sin restricciones, la salida no es cacheable (el caching se trata de tokens de entrada).
Diagnóstico simple. Registra los primeros 2,000 caracteres de cada request de API por un día. Cuenta cuántos son idénticos. Si >50% de tus requests comparten un prefijo común de más de 1,000 tokens, el prompt caching te ahorrará dinero sustancial. Si <20%, el ahorro no justifica el esfuerzo de implementación del caching explícito (aunque el caching automático aún proporciona ahorro pasivo).
Diagnóstico de tasa de cache hit: un script de 5 minutos
Antes de tocar el código de producción, verifica que tu carga sea amigable con el caché. Ejecuta este script contra tus últimos 1,000 requests de API. Hace hash de la parte cacheable de cada request y reporta tu tasa de duplicación —el porcentaje de requests que comparten un prefijo con al menos otro request.
import hashlib
import json
from collections import Counter
# Load your request log —adapt the path and format to your setup
with open("api_requests.jsonl") as f:
requests = [json.loads(line) for line in f]
def get_cacheable_prefix(req):
"""Extract the static portion of each request.
For most applications this is the system prompt + any messages
before the final user turn."""
messages = req.get("messages", [])
prefix = messages[:-1] if len(messages) > 1 else messages
return json.dumps(prefix, sort_keys=True)
prefixes = [get_cacheable_prefix(r) for r in requests]
hashes = [hashlib.md5(p.encode()).hexdigest() for p in prefixes]
counts = Counter(hashes)
total = len(requests)
unique = len(counts)
most_common = counts.most_common(1)[0] if counts else (None, 0)
dup_rate = (total - unique) / total * 100 if total else 0
print(f"Total requests analyzed: {total}")
print(f"Unique prefixes: {unique}")
print(f"Most-repeated prefix: {most_common[1]} occurrences")
print(f"Duplication rate: {dup_rate:.1f}%")
if dup_rate > 70:
print("=> Cache-friendly. Implement explicit caching —high ROI.")
elif dup_rate > 40:
print("=> Borderline. Caching helps, but audit write costs first.")
else:
print("=> Not cache-friendly. Skip caching; use other optimizations.")Qué significan los números para tu factura. Una tasa de duplicación del 70% en 500 requests diarios con un system prompt de 10,000 tokens a $5/M de entrada significa que 350 requests se benefician del caching. Con el descuento del 90% de Anthropic, los tokens cacheados cuestan $0.50/M en lugar de $5/M —ahorrando $15.75/día solo en ese bloque. Con el descuento automático del 50% de OpenAI, ahorras $8.75/día con cero cambios de código. Incluso una tasa del 40% importa: 200 requests/día a 10,000 tokens ahorra $9/día en Anthropic.
¿Sin acceso a los logs de requests? El dashboard de tu proveedor de LLM muestra el recuento total de requests y los tokens promedio por request. Cruza los datos con el MAU de tu aplicación. Si sirves a 100 usuarios activos diarios con un system prompt fijo de 5,000 tokens, tienes 100 prefijos idénticos. Si cada usuario sube un documento único de 20 páginas por sesión, tu tasa de duplicación se redondea a cero. El dashboard te dice en qué categoría estás sin rascar ni una línea de log.
Cuando el prompt caching te cuesta dinero
La mayoría del tiempo, el prompt caching ahorra dinero. Pero bajo las condiciones equivocadas, hace lo contrario —pagas más y no recibes nada a cambio. Estos son los escenarios donde deberías pensarlo dos veces antes de agregar controles de caché.
El premium de escritura de Anthropic en cargas de baja tasa de hits. Anthropic cobra 1.25x el precio base de entrada por cada escritura de caché. Si tu tasa de hits cae por debajo del 20%, el premium de escritura excede el descuento de lectura. Un bloque cacheado de 10,000 tokens a $5/M base: la escritura cuesta $0.0625 (1.25x), la lectura cuesta $0.005 (0.1x). Necesitas aproximadamente 1.3 requests totales por escritura para el punto de equilibrio —es decir, incluso una sola lectura de caché (2 requests totales compartiendo el mismo prompt) ahorra ~32.5%. Un bot de soporte que rota su system prompt cada 3 requests (1 escritura + 2 lecturas) ahorra ~52% vs. sin caching. Monitorea cache_read_input_tokens vs cache_creation_input_tokens en la respuesta de usage de Anthropic. Si la relación lectura-a-escritura está por debajo de 0.5:1 (menos de 1 lectura por cada 2 escrituras), elimina el bloque de caché.
Cargas intensivas en streaming y de una sola vez. Transcripción en tiempo real, generación de código de una sola vez, escritura creativa —cada prompt es único por diseño. Agregar bloques cache_control a un flujo de prompts únicos agrega ~20 tokens por bloque a cada request y nunca devuelve un cache hit. El caching automático de OpenAI los omite silenciosamente (sin hit, sin cargo). Pero los bloques cache_control explícitos de Anthropic siempre incurren el costo de escritura en la primera aparición. En cargas únicas, cada request es una primera aparición —pagas el premium del 25% en cada llamada con cero ahorro compensatorio.
Prompts que caen justo por debajo del umbral mínimo. Anthropic requiere 4,096 tokens para Opus 4.5+ y Haiku 4.5, y 2,048 tokens para Sonnet 4.6. OpenAI requiere 1,024 tokens. Un system prompt de 1,500 tokens con un bloque cache_control en Opus cuesta lo mismo que uno sin él —el proveedor ignora silenciosamente la directiva de caché porque cae por debajo del mínimo de 4,096 tokens. Un bloque cache_control agrega ~20 tokens. A 5 millones de requests/mes y $5/M de entrada, esos 20 tokens desperdiciados cuestan $500/mes. Verifica tu recuento real de tokens (no tu recuento de caracteres) con el tokenizador del proveedor antes de agregar controles de caché.
Regla rápida. Solo invierte en caching explícito cuando: (a) tu prefijo cacheable excede 1,024 tokens, (b) aparece en más del 50% de los requests, y (c) tu intervalo medio de requests está por debajo del TTL del proveedor. Si falla alguna condición, deja que el caching automático lo maneje o salta el caching por completo y elige otra estrategia del playbook de optimización de costos.
Guía de estrategia de caching
La jerarquía. Anthropic para máximo ahorro en cachés explícitos de alta frecuencia. DeepSeek para el precio absoluto más barato de lectura en cargas de alto volumen. Google para cachés de documentos de TTL largo (hasta 24 horas). OpenAI para ahorro automático sin esfuerzo.
La estrategia de caché multi-proveedor. Cachea tu contenido estático en el proveedor con la mejor economía de caché (Anthropic, 90% de descuento). Enruta el tráfico amigable con el caché a ese proveedor. Enruta requests únicos al proveedor con el mejor precio base para tu caso de uso. Esta es una optimización avanzada —implementa primero el caching básico, ajusta el enrutamiento después.
Caching a nivel de plataforma. Algunas plataformas de agregación superponen su propio caching sobre el caching del proveedor. La plataforma cachea respuestas a nivel de API gateway —requests idénticos servidos desde el caché de la plataforma nunca llegan al proveedor. Para aplicaciones de alto volumen con patrones de consulta repetitivos, esto duplica el ahorro. La documentación de prompt caching de TokSpan cubre la configuración del caching a nivel de plataforma, incluyendo análisis de hits y seguimiento de ahorro por proveedor.
FAQ
¿Cuánto puedo realmente ahorrar con prompt caching?
50–90% en tokens de entrada, según el proveedor y la carga. Con Anthropic (90% de descuento) y 80% de tokens de entrada cacheados: el costo efectivo de entrada cae ~72%. En un gasto de entrada de $1,000/mes, eso es $280/mes —$720/mes de ahorro.
¿Necesito cambiar mi código?
OpenAI y DeepSeek: no, el caching es automático. Anthropic: sí, agrega bloques cache_control (3 líneas de código). Google: sí, crea recursos de contenido cacheado. El esfuerzo de implementación es proporcional al ahorro —Anthropic requiere más código pero ofrece el mayor descuento.
¿Cuánto duran los cachés?
Anthropic: ~5 minutos. OpenAI: 5–60 minutos (variable, no garantizado). Google: TTL configurable (de minutos a 24 horas, con mayor costo para TTL más largos). DeepSeek: similar a OpenAI. Para aplicaciones con intervalos de requests bajo 5 minutos, el caching funciona automáticamente. Para patrones de acceso menos frecuentes, solo el TTL configurable de Google ayuda.
¿Puedo cachear entre diferentes modelos del mismo proveedor?
Generalmente no. El caché es específico del modelo. Cambiar de Opus a Sonnet invalida el caché. Fija versiones específicas de modelos en producción para maximizar las tasas de hits.
¿Qué pasa si mi caché expira a mitad de la conversación?
El proveedor vuelve al precio completo para los tokens afectados —sin error, sin interrupción, solo mayor costo para ese request. La experiencia del usuario no se ve afectada. La expiración del caché es un evento de costo, no de confiabilidad. Bajo riesgo, alta recompensa.
El prompt caching entrega hasta 90% de ahorro con casi nada de código —un raro almuerzo gratis en infraestructura. Pero los almuerzos gratis tienen una historia de ser incluidos en el precio. A medida que el caching se vuelve estándar en cada proveedor, la pregunta real es si los descuentos de hoy sobrevivirán el próximo ciclo de precios, o si el ahorro se incorporará silenciosamente en tasas base más altas mientras el marketing sigue igual.
Si la ventana de descuento se cierra, la pregunta no es si el caching valió la pena implementarlo —el ahorro incluso de seis meses de tokens de entrada con 90% de descuento justifica con creces las tres líneas de código que se necesitaron para habilitarlo. Configura prompt caching en TokSpan y superpón caching a nivel de plataforma sobre el descuento integrado de cada proveedor mientras la economía aún lo favorezca tan fuertemente.