¿Qué es el almacenamiento en caché de prompts? Cómo se reutiliza un prompt repetido

El almacenamiento en caché de prompts significa que la API recuerda el comienzo de tu solicitud y lo reutiliza la próxima vez que envías el mismo comienzo. Sigues enviando el texto completo en cada llamada, pero el proveedor puede saltarse el trabajo de volver a leer la parte repetida, y algunos proveedores facturan esa parte a una tarifa menor. Solo funciona sobre el inicio de la solicitud, y solo si ese inicio es idéntico.

El bot de soporte que no deja de releer la misma página#

Supón que tienes un bot de soporte con 2.000 tickets al día. Cada solicitud empieza con los mismos 3.000 tokens: tono de voz, reglas de reembolso, política de envíos. Después viene el mensaje del cliente en una línea, algo como "¿Dónde está mi pedido?" (Si los tokens aún te resultan difusos, empieza por qué es un token.)

Sin caché, el proveedor vuelve a leer los 3.000 tokens de reglas para el ticket número 1, el ticket número 2 y el ticket número 2.000. La misma página, leída 2.000 veces. Con caché, la primera solicitud paga el precio completo de leerla, y las solicitudes posteriores que empiezan con el mismo texto pueden reutilizar el trabajo.

La guía de la API de DeepSeek (consultada el 24 de octubre de 2026) describe exactamente esto: el almacenamiento en caché de contexto está activado por defecto, no requiere cambios en el código, y una solicitud posterior con un prefijo solapado cuenta como "acierto de caché". Solo se almacena en caché la entrada. La respuesta se genera de nuevo cada vez.

Qué cuenta como "lo mismo": la regla del prefijo#

La caché compara desde el primer carácter en adelante. En el momento en que tu solicitud difiere de la almacenada, todo lo que viene después de ese punto es nuevo. Por eso el orden de tu solicitud importa más que su longitud.

Aquí está el error que mata la caché en silencio. Un desarrollador quiere que el bot conozca la hora y la pone al principio:

Current time: 14:03:22
You are a support assistant for a shop...
(3,000 tokens of rules)

La hora cambia cada segundo, así que la primera línea difiere en cada solicitud, y nada de lo que viene después puede coincidir. La solución es mover lo que cambia al final:

You are a support assistant for a shop...
(3,000 tokens of rules)
Current time: 14:03:22
Customer: Where is my order?

Ahora los 3.000 tokens de reglas van primero y permanecen idénticos. La misma lógica cubre los otros dos casos habituales: un chat largo reenvía todo su historial en cada turno, así que los mensajes antiguos son un inicio repetido ya listo (más sobre esto en por qué un chat largo cuesta más), y un agente repite sus definiciones de herramientas e instrucciones en cada paso.

El almacenamiento en caché también es de mejor esfuerzo. DeepSeek dice que la caché tarda unos segundos en construirse, que un acierto necesita una coincidencia completa de una unidad de prefijo de caché existente, que no hay una tasa de aciertos garantizada, y que las cachés sin usar se borran, normalmente en cuestión de horas o días. Así que una segunda solicitud lanzada medio segundo después de la primera puede que aún no acierte, y el acierto puede cubrir menos que todo tu prefijo.

Cómo verlo: los campos de caché en usage#

No tienes que adivinar si funcionó. Cada proveedor lo informa en la parte usage de la respuesta, con sus propios nombres de campo.

DeepSeek usa dos campos:

• prompt_cache_hit_tokens — tokens de entrada que se encontraron en la caché
• prompt_cache_miss_tokens — tokens de entrada que no

Supón que tu primer ticket de soporte vuelve con prompt_cache_hit_tokens: 0 y prompt_cache_miss_tokens: 3200, y un ticket un minuto después muestra prompt_cache_hit_tokens: 3000 y prompt_cache_miss_tokens: 200. Se reutilizaron los 3.000 tokens de reglas; solo el nuevo mensaje del cliente y unos pocos tokens se leyeron desde cero. Si el número de aciertos se queda en cero en cada llamada, mira el inicio de tu solicitud: algo ahí está cambiando.

Anthropic funciona de otra manera, porque tú marcas qué almacenar en caché. Añades cache_control con tipo ephemeral a la solicitud o a un bloque de contenido:

{
  "model": "your-model-id",
  "max_tokens": 300,
  "system": [
    {
      "type": "text",
      "text": "You are a support assistant... (long rules)",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "Where is my order?"}]
}

Según la documentación de almacenamiento en caché de prompts de Anthropic (consultada el 24 de octubre de 2026), la respuesta informa tres números: cache_creation_input_tokens (escrito en la caché ahora), cache_read_input_tokens (leído de ella) y input_tokens (lo que vino después del último punto de corte de caché). Supón que la primera llamada muestra cache_creation_input_tokens: 10000, cache_read_input_tokens: 0; la segunda muestra 0 y 10000. Eso es una escritura en caché seguida de una lectura de caché.

Hay una trampa en pantalla. Los prompts más cortos que el mínimo del modelo (512, 1.024 o 4.096 tokens, según el modelo) se procesan sin almacenamiento en caché y sin error. Verás ceros en ambos campos de caché y ninguna advertencia. La vida útil por defecto es de 5 minutos, renovada gratis en cada uso; un ttl opcional de 1h la mantiene más tiempo.

Qué le hace a tu factura#

El almacenamiento en caché cambia el precio de la parte repetida, así que vale la pena hacer el cálculo una vez. Anthropic indica multiplicadores sobre el precio base de entrada: una escritura en caché con la vida útil de 5 minutos cuesta 1,25×, una lectura cuesta 0,1× (0,05× para Opus 5.5 y Sonnet 5.5). Toma un prefijo de 10.000 tokens reutilizado en 20 solicitudes dentro de la ventana de 5 minutos, usando la lectura estándar de 0,1×:

10.000 × 20 = 200.000 tokens al precio base sin caché

10.000 × 1,25 = 12.500 para la primera solicitud que escribe la caché

19 × 10.000 × 0,1 = 19.000 para las 19 solicitudes que la leen

12.500 + 19.000 = 31.500 equivalentes de token con caché

Así que la parte repetida cuesta bastante menos de una quinta parte del importe sin caché. La pega: si los 5 minutos transcurren entre solicitudes, la siguiente vuelve a escribir la caché a 1,25×, y un prefijo que se usa poco puede acabar costando más que no tener caché en absoluto.

Ahora el bot del principio, como línea base simple a precio completo. 2.000 solicitudes al día, 3.000 tokens de entrada y unos 300 tokens de salida cada una:

2.000 × 3.000 = 6.000.000 tokens de entrada al día

2.000 × 300 = 600.000 tokens de salida al día

La tabla pone precio a la carga de trabajo de ese día en cada modelo disponible de CheapTokens junto a OpenRouter:

DeepSeek-V4-Flash es más barato que OpenRouter en total, contando entrada y salida juntas, y la carga de trabajo cabe holgadamente: contexto de 380K y hasta 32.768 tokens de salida por respuesta. Este es el coste a precio completo de la carga de trabajo: tokens de entrada × precio por token. Un prefijo largo y estable es donde esa parte de entrada es mayor.

Pruébalo tú mismo en cinco minutos#

El plan: enviar el mismo prompt de sistema largo dos veces con preguntas distintas y mirar usage. Pon tu propio texto de reglas en support_rules.txt (una o dos páginas de texto bastan). El endpoint es la API de CheapTokens compatible con OpenAI, y puedes tomar la clave de tu cuenta.

from openai import OpenAI

client = OpenAI(base_url='https://api.cheaptokens.dev/v1', api_key='YOUR_API_KEY')

SYSTEM = open('support_rules.txt').read()  # long, never changes

for question in ['Where is my order?', 'Can I change the address?']:
    r = client.chat.completions.create(
        model='deepseek-ai/DeepSeek-V4-Flash-0731',
        messages=[
            {'role': 'system', 'content': SYSTEM},
            {'role': 'user', 'content': question},
        ],
        max_tokens=300,
    )
    print(r.usage)

Qué revisar en la salida: prompt_tokens te dice qué tan grande es tu solicitud. Ambas solicitudes llevan el mismo texto SYSTEM, así que la mayor parte de ese número se repite de una solicitud a la siguiente — aproximadamente el tamaño de tu archivo de reglas. Ese inicio repetido es la parte que un proveedor con caché, como la API de DeepSeek o Anthropic de arriba, puede reutilizar. Ahora un ejercicio sobre el orden: añade una línea con la hora actual (datetime.now()) al principio de SYSTEM y ejecuta de nuevo. Las dos solicitudes ya no comparten un inicio, porque difieren desde la primera línea. Pon la misma línea al final del prompt y el inicio compartido vuelve.

Una lista de comprobación breve para tus propios prompts:

1. Texto estable primero: instrucciones, reglas, definiciones de herramientas, ejemplos.
2. Texto cambiante al final: fecha, nombre de usuario, el último mensaje.
3. Mantén el prefijo idéntico byte a byte — incluso un espacio extra cuenta.
4. Comprueba el tamaño mínimo del proveedor antes de preguntarte por qué no se almacena nada en caché.
5. Mira los campos de usage después de un cambio, no antes.

Para poner precio a tu propia carga de trabajo, abre la página de precios e introduce tus tamaños de entrada y salida, o empieza por la página de DeepSeek. Una vez que la primera solicitud funciona, la misma estimación tarda un minuto para cualquier prompt que escribas. Para saber cuánto cuestan los dos lados de una solicitud, consulta tokens de entrada vs salida.