Prompt caching para agentes de IA: cómo bajar costo y latencia

Un agente no paga una llamada. Paga el mismo system prompt, las mismas tools y el mismo contexto en cada turno. Si eso vive al inicio del prompt y no cambia, el proveedor puede reutilizar el prefijo: menos latencia de prefill y input hasta 10 veces más barato en un cache hit. Si el timestamp, el user id o el orden de las tools se cuelan al principio, el hit rate cae a cero y la factura se parece a no tener caché.

Esta guía no es un desglose de hosting —eso está en cuánto cuesta un agente—. Aquí el único tema es cómo diseñar el prompt para que el caché pegue.

Qué cachea de verdad

Ni OpenAI ni Anthropic guardan el texto del prompt para reenviártelo. Cachean el estado intermedio (tensores KV) del prefijo ya procesado. La regla es la misma: el prefijo tiene que ser idéntico hasta el breakpoint.

OpenAI cachea el contexto renderizado: instrucciones del proveedor, developer messages, definiciones de tools e historial (texto, imágenes, documentos y audio soportado). El caché está activado por defecto en modelos soportados. Un cambio de model, tools, text.format, reasoning.effort o compactación corta el prefijo a partir de ese token.

Anthropic cachea en este orden: tools → system → messages. Un cambio en tools invalida tools, system y messages. Tienes dos modos:

1. Automático: un cache_control de nivel request; el breakpoint se mueve al último bloque cacheable (útil en multi-turno).
2. Explícito: cache_control en bloques concretos, hasta 4 breakpoints.

TTL por defecto en Anthropic: 5 minutos, renovado en cada hit. El TTL de 1 hora existe y el write cuesta 2× el input base. OpenAI, en GPT-5.6 y posteriores, usa TTL mínimo de 30 minutos (prompt_cache_options.ttl: "30m"); modelos anteriores usan prompt_cache_retention (in_memory o 24h).

Precios públicos (verifica la página vigente)

Multiplicadores que sí están en las docs, no en un tweet:

Proveedor	Write	Read (hit)	Mínimo cacheable
OpenAI GPT-5.6 y posteriores	1,25× el input	0,1× el input	1.024 tokens visibles
OpenAI modelos anteriores a GPT-5.6	sin recargo de write	tarifa cached-input del modelo	2.048 tokens visibles (algunos aceptan menos)
Anthropic (5 min)	1,25× el input	0,1× el input (0,025× en Fable/Mythos 5.1)	512–4.096 según modelo
Anthropic (1 h)	2× el input	igual que el hit de 5 min	igual

Números de referencia por 1M de tokens, tomados de las tablas públicas el día de esta guía:

Modelo	Input	Write caché	Read caché	Output
OpenAI gpt-5.6-terra (contexto corto)	USD 2,00	USD 2,50	USD 0,20	USD 12,00
Anthropic Claude Sonnet 5	USD 2,00	USD 2,50 (5 min) / USD 4,00 (1 h)	USD 0,20	USD 10,00

Un write + un read completo en GPT-5.6 cuesta 1,35× un input suelto; diez requests (1 write + 9 reads) cuestan 2,15× frente a 10× sin caché. Eso lo dice OpenAI, no un benchmark interno.

Si tu prefijo no llega al mínimo, el proveedor procesa sin cachear y no lanza error. En Anthropic, cache_creation_input_tokens y cache_read_input_tokens en 0 significan que no hubo caché. En OpenAI mira usage.input_tokens_details.cached_tokens y el Prompt Caching Dashboard.

Cómo estructurar el prompt del agente

Pon lo estático primero. Lo que cambia por turno, al final.

1. Definiciones de tools (nombres, schemas, orden fijos)
2. System / developer: rol, políticas, formato
3. Base de conocimiento o ejemplos few-shot
   └── breakpoint aquí
4. Historial reciente (o resumen, no un timestamp)
5. Mensaje del usuario de este turno

El error más caro, documentado por Anthropic: poner el breakpoint en el bloque que cambia (reloj, request id, “hoy es…”). El lookback busca escrituras previas en esa posición, no “contenido parecido detrás”. Resultado: pagas write en cada request y nunca lees.

En Anthropic el lookback es de 20 bloques por breakpoint. Si el hilo crece más de 20 bloques desde el último write, el hit se pierde salvo que hayas dejado un segundo breakpoint más atrás. En OpenAI GPT-5.6, hasta 4 writes por request y hasta 50 breakpoints recientes para el read más largo.

Código mínimo que sí pega

Anthropic, breakpoint en el system estático —no en el user:

const response = await anthropic.messages.create({
  model: "claude-sonnet-5",
  max_tokens: 512,
  tools,
  system: [
    {
      type: "text",
      text: systemEstatico, // políticas + KB; sin fecha
      cache_control: { type: "ephemeral" },
    },
  ],
  messages: [{ role: "user", content: turnoActual }],
});

const { cache_creation_input_tokens, cache_read_input_tokens } =
  response.usage;

OpenAI GPT-5.6, modo implícito (breakpoint al final del último mensaje elegible) más prompt_cache_key cuando hay más de ~15 rpm y el router puede mandarte a otra máquina:

const response = await openai.responses.create({
  model: "gpt-5.6-terra",
  prompt_cache_key: `soporte:${tenantId}`,
  input: [
    { role: "developer", content: systemEstatico },
    { role: "user", content: turnoActual },
  ],
});

Las tools van en el mismo orden siempre. Reordenar el array o cambiar una descripción invalida el prefijo. El contrato de tools está en function calling confiable; el caché solo funciona si ese contrato es estable.

No metas el RAG completo delante del breakpoint si el retrieve cambia cada turno. Recupera después del prefijo cacheado, o cachea un corpus fijo y deja el chunk dinámico fuera. Eso encaja con la guía de memoria y RAG.

Ejemplo: 10.000 conversaciones

Agente de soporte con prefijo estático de 4.000 tokens (system + 8 tools + políticas), 500 tokens dinámicos por turno y 300 tokens de salida. Un turno por conversación. Modelo: gpt-5.6-terra.

Escenario	Input 4k prefijo	Input 0,5k dinámico	Output 0,3k	Total
Sin caché	40M × USD 2,00 = USD 80	5M × USD 2,00 = USD 10	3M × USD 12 = USD 36	USD 126
Caché continuo (1 write + 9.999 reads)	write 4k × USD 2,50 ≈ USD 0,01; reads ≈ 40M × USD 0,20 = USD 8	USD 10	USD 36	≈ USD 54

El ahorro está en el prefijo, no en la salida. Si el agente escribe ensayos, el modelo económico y el routing importan más que el caché.

Tres supuestos explícitos: un turno por conversación, tráfico continuo que renueva el TTL sin rewrites, y prefijo idéntico entre tenants. Si cada tenant tiene tools distintas, usa prompt_cache_key por tenant; no mezcles prefijos.

Checklist de hit rate

1. Prefijo ≥ mínimo del modelo (1.024 / 2.048 / 512–4.096).
2. Tools, system y KB antes del user message.
3. Sin reloj, nonce ni user id dentro del prefijo.
4. Mismo model y mismo orden de tools.
5. Breakpoint en el último bloque estable, no en el que cambia.
6. Loguea cached_tokens / cache_read_input_tokens por request.
7. OpenAI a >15 rpm: prompt_cache_key estable por prefijo.
8. Anthropic multi-turno largo: segundo breakpoint antes de 20 bloques.
9. Requests paralelos: el write solo existe cuando empieza la primera respuesta; no dispares 50 en frío esperando hit.
10. Compactación / context editing: asume miss desde el primer token cambiado.

Preguntas frecuentes

¿El caché filtra PII? No. Es un atajo de cómputo, no un vault. Sigue las reglas de fugas de datos. OpenAI no comparte caché entre organizaciones ni entre regiones.

¿Sirve para un bot de Telegram? Sí, si el system y las tools no cambian por chat. La memoria por conversación va después del breakpoint. El adaptador del canal está en bot de Telegram.

¿Gemini? Google documenta context caching aparte (caché explícito con nombre y TTL). No lo mezcles con el prefijo implícito de OpenAI/Anthropic el día uno.

¿Vale la pena con prompts cortos? Si no llegas al mínimo, no. Alarga el prefijo con políticas y few-shot reales, no con relleno.

El siguiente paso

Mide 50 turnos reales y anota hit rate y costo por tarea terminada, no precio por millón. Cuando el prefijo sea estable, el resto es cola, retries e idempotencia en la arquitectura de producción. El curso gratis de instalación arma el primer agente; el hub de costos agrupa operación y factura.