Ventana de contexto para agentes: recortar, cachear y no pudrir el prompt

Meter “todo el historial + el PDF + las tools” en cada request no es memoria: es context rot. Claude lo nombra así: a más tokens, peor recall. Una ventana de 200k no te da permiso de usarla. Esta guía cubre qué cuenta como contexto, cómo cachear el prefijo estable y cuándo compactar en vez de concatenar.

Complementa memoria y RAG: RAG es documentos fuera de la ventana; esto es qué cabe en el request de hoy. Fuentes del 3 de septiembre de 2026.

Qué es la ventana (y qué no)

Claude: la ventana es todo el texto que el modelo puede referenciar al generar, incluida su propia respuesta. No es el corpus de entrenamiento. Tool use y extended thinking cuentan. Si dejas thinking + 40 tool results + el hilo, te comes el presupuesto sin que el usuario haya dicho mucho.

Más contexto ≠ mejor. Curar importa tanto como el tamaño. El artículo de Anthropic Effective context engineering for AI agents es la lectura larga; aquí el mínimo operable.

Tres palancas, en este orden

1. No pongas en el prompt lo que una tool puede devolver. El manual de 80 páginas vive en RAG o en search_docs, no en el system. Cada request carga solo el hit.
2. Cachea el prefijo que no cambia. System + tools + políticas.
3. Compacta o recorta el hilo cuando te acercas al techo. Claude recomienda server-side compaction como estrategia principal en agentes largos.

Si haces 3 antes de 1, estás resumiendo basura cara.

Prompt caching: OpenAI vs Claude

OpenAI documenta caching encendido por defecto en modelos soportados. El cache guarda estados KV, no los tokens. Si el siguiente request comparte el mismo prefijo, reutiliza ese trabajo:

• Más barato: input cacheado con descuento hasta 90%.
• Más rápido: menos tiempo de procesamiento antes del primer token.
• Dashboard de hit rate en platform.openai.com/usage (sección prompt caching).

Implicación para un agente: no reordenes system / tools / developer messages entre requests. Un byte distinto al inicio invalida el prefix. Pon lo variable (el turno del usuario, el resultado fresco de la tool) al final.

Claude: hay que pedirlo. Dos modos oficiales:

• Automatic caching: un cache_control a nivel request. El sistema pone el breakpoint en el último bloque cacheable y lo mueve a medida que crece la conversación. Pensado para multi-turno.
• Explicit breakpoints: cache_control en bloques concretos. Control fino.

TTL documentado: 5 minutos o 1 hora. Si tu agente habla una vez al día, el cache de 5 min no te sirve; el de 1 h a veces sí. Si habla cada 10 s, 5 min es el default razonable.

Gemini documenta long context como capacidad del modelo (ventanas grandes). Eso no sustituye curar ni cachear: una ventana enorme sigue costando y sigue pudriéndose.

Compaction vs. recorte bruto

Recorte bruto: tiras los turnos viejos. Barato, pierde decisiones.

Compaction (Claude, server-side): el proveedor resume/compacta el hilo y te deja seguir el mismo agente. Es la estrategia que Claude marca como primaria para workflows largos.

Regla práctica:

• Turnos 1–15: no toques nada. Cachea el prefix.
• Cuando el usage de input pase ~40–50 % de la ventana: compacta o resume a un “estado de tarea” (qué se decidió, qué IDs existen) y borra los tool results crudos.
• Los artefactos (diff, id de ticket, URL) salen a memoria durable, no se quedan 40 veces en el chat.

Checklist

• System + tools idénticos byte a byte entre requests (cache hit).
• Lo variable al final del prompt.
• Tool results grandes no se reenvían enteros en el turno siguiente; queda un resumen + id.
• Umbral de compactación medido en tokens de input, no en “número de mensajes”.
• Thinking de Claude no se reinyecta si no lo necesitas (cuenta para la ventana).
• Log de cached_tokens / cache hits. Si es 0, el prefix se está rompiendo.
• Eval de recall: “¿sigues sabiendo el order_id del turno 2 después de compactar?”
• Costo por run bajando cuando el cache pega; si no, el cache no está haciendo nada.

FAQ

¿Una ventana de 1M me ahorra RAG? No. RAG es permisos, frescura y costo. 1M tokens de PDF en cada request es una factura, no una arquitectura.

¿Puedo cachear el resultado de una tool? El cache es de prefijo. Un tool result que cambia cada turno no cachea. Cachea instrucciones y schemas; el result va al final.

¿Resumir con otro modelo? Sí, como compaction casera. Mide que el resumen conserve IDs y decisiones. Un resumen literario es inútil para un agente.

¿Gemini long context cambia esto? Te da más margen antes de compactar. Context rot y costo siguen. Curar igual.

Empieza por congelar el prefix (system+tools) y mirar el hit rate una semana. Si es 0, no tienes un problema de ventana: tienes un prompt que se reescribe solo.