Qué cambió realmente en el almacenamiento en caché de GPT-6
Las mejoras de almacenamiento en caché de indicaciones de GPT-6 se reducen a dos cambios concretos: puntos de interrupción cache_control explícitos y tasas de acierto más altas reportadas que la serie GPT-5. En lugar de depender de la coincidencia de prefijos implícita, ahora declara dónde termina el contexto almacenable en caché. OpenAI reporta tasas de acierto de 70%+ en bucles sostenidos, frente al 40–50% con la lógica basada en sufijos de GPT-5.
La mecánica importa para el argumento. Cada respuesta de API ahora incluye cache_read_input_tokens, cache_creation_input_tokens, y uncached_input_tokens. Los tokens almacenados en caché cuestan aproximadamente el 10% del precio del token de entrada—así que un contexto de 150k tokens reutilizado en un bucle de 20 turnos podría ahorrar $1.20 por sesión si realmente acierta el caché. El TTL es de 5 minutos por defecto, extensible a 1 hora. Si se pierde la ventana a mitad del bucle, se vuelve a facturar el prefijo completo.
Aquí es donde el trabajo anterior de Anthropic con bloques cache_control importa: OpenAI aprendió la lección. La coincidencia de prefijos implícita se fragmentaba demasiado fácilmente cuando los resultados de herramientas o fragmentos recuperados aterrizaban en el medio de la indicación. Los puntos de interrupción explícitos son más seguros, pero solo si entiende qué rompe la localidad del caché.
Razonamiento sostenido sobre documentos estáticos: donde los ahorros son reales
La victoria es clara en un modo específico: un agente de investigación masticando un código base fijo, conjunto de contratos, o base de conocimiento durante 10–30 turnos sin obtener datos nuevos. Su indicación del sistema, esquemas de herramientas, ejemplos de pocos disparos, y la mayor parte de su contexto estático se sientan antes de un punto de interrupción. A través de turnos, el agente refina su razonamiento, llama herramientas, y aprende—pero el prefijo almacenado en caché nunca cambia.
Hemos enviado flujos de trabajo como este. Un agente de análisis de contratos comienza con un contexto de 200k tokens: indicación del sistema, herramientas de extracción, ejemplos similares, y el texto completo del contrato. Durante 20 turnos, hace preguntas aclaratorias, refina extracciones estructuradas, y señala ambigüedades. El primer turno factura 200k tokens para la creación de caché. Los turnos 2–20 cada uno facturan aproximadamente 1–2k tokens nuevos (la nueva pregunta, el intercambio anterior) contra un acierto de 200k. El costo por turno cae de $0.60 a $0.09. Medido. Real.
Por qué esto se escala vale la pena declarar claramente: los flujos de trabajo, no los agentes abiertos, son donde vive este modo. El agente no está tomando decisiones sobre qué datos obtener a continuación; está razonando sobre un corpus precargado. Si puede describir el trabajo como un diagrama de flujo con las mismas entradas para cada turno, el almacenamiento en caché lo ayudará.
Los bucles de recuperación agéntica rompen la localidad del caché
El modo de fallo es igualmente concreto. Cada turno su agente emite una llamada de herramienta de recuperación—búsqueda, consulta de base de datos, búsqueda web, búsqueda de fragmento RAG—y prepone esos resultados en la indicación, desplaza el sufijo almacenable en caché. La indicación del sistema y las definiciones de herramientas permanecen almacenadas en caché, pero el historial de conversación y los fragmentos recuperados son nuevos. La tasa de acierto se desmorona.
Este es el bucle de agente que parece que debería almacenarse en caché pero no lo hace. Tiene un par planificador-ejecutor: el planificador lee una solicitud del usuario y el contexto del turno anterior, decide qué herramienta de recuperación llamar, y el ejecutor devuelve fragmentos. En el turno 2, los fragmentos son diferentes. La estructura de la indicación es idéntica, pero cache_creation_input_tokens factura nuevamente porque el contenido semántico cambió. A través de una búsqueda de múltiples saltos de 20 turnos, su tasa de acierto permanece atrapada alrededor del 20–30% en lugar del prometido 70%.
Una corrección parcial: mueva todo el contexto recuperado a la cola de la indicación, después de un punto de interrupción final. Si su indicación es [sistema] [herramientas] [conversación] [fragmentos recuperados], marque el punto de interrupción después de [herramientas]. La conversación y los fragmentos permanecen dinámicos, pero almacena en caché el costoso prefijo estático. Recupera algunos aciertos, pero ahora está facturando el mismo historial de conversación varias veces a medida que crece. El compromiso es real; las matemáticas cambian con el tamaño del contexto.
La cascada importa: un token cambiado en el prefijo rompe cada acierto posterior para esa sesión. Una marca de tiempo ecoada en la indicación, un ID de solicitud, un ID de usuario en un mensaje—cualquiera de estos invalida todo el prefijo almacenado en caché. Hemos cometido este error antes.
Instrumente primero, optimice segundo
Antes de reescribir indicaciones alrededor de puntos de interrupción, mida en qué modo realmente está. Registre tres números por turno: cache_read_input_tokens, cache_creation_input_tokens, uncached_input_tokens. Calcule una tasa de acierto rodante como cache_read / (cache_read + cache_creation + uncached). Etiquete cada turno con un campo de modo: reuse, retrieval, o planner.
Su panel debería mostrar la tasa de acierto versus el índice de turno. La forma le cuenta la historia. Un bucle de razonamiento sostenido muestra la tasa de acierto subiendo hacia 80–90% en el turno 5 y manteniéndose. Un bucle de recuperación muestra la tasa de acierto estancada alrededor del 15–25%. Un bucle planificador-ejecutor con fragmentos recuperados inyectados muestra la tasa de acierto cayendo a través de turnos a medida que el historial de conversación crece sin facturar. Esta es la granularidad que su observabilidad de agente necesita—no solo si el caché acierta, sino por qué los aciertos de caché fallan y qué cambió en la indicación para causarlo.
Establezca una alerta para el colapso de tasa de acierto a mitad de sesión. Si una sesión comienza con una tasa de acierto del 70% y cae por debajo del 60% en el turno 10, algo rompió la localidad del caché. Se agregó una nueva herramienta de recuperación, cambió un ordenamiento de mensajes, o expiró el TTL. Quiere saber antes de que llegue la factura. Correlacione la tasa de acierto con la latencia de reloj de pared y el costo total, no solo el recuento de tokens.
Arquitectura de indicación que gana el caché
Si se está comprometiendo con el almacenamiento en caché, estructure su indicación deliberadamente. Coloque puntos de interrupción en este orden: después de la indicación del sistema, después de esquemas de herramientas y definiciones, después de documentos estáticos o ejemplos. Los fragmentos recuperados, resultados de herramientas, e historial de conversación vienen después del punto de interrupción final.
Restricciones prácticas: evite ecoar marcas de tiempo, IDs de solicitud, identificadores de usuario, o cualquier metadato dinámico en el prefijo almacenado en caché. Si los necesita para auditoría, páselos como metadatos fuera de la indicación. Reordenar mensajes para compatibilidad con caché puede degradar la calidad del razonamiento—el LLM puede razonar mejor con un orden de mensaje específico. Pruebe empíricamente; no asuma que la ganancia de caché supera la pérdida de calidad.
Sepa cuándo dividir: si una subtarea implica recuperación pesada, déle su propio subaagente con una indicación corta (2–3k tokens) y sin gastos generales de almacenamiento en caché. Deje que el agente padre almacene en caché el contexto de razonamiento estático; el agente hijo absorbe la agitación de recuperación. Esto se asigna limpiamente a la arquitectura del flujo de trabajo: un planificador almacenado en caché que orquesta recuperadores sin caché.
Cuando el almacenamiento en caché es teatro — y qué optimizar en su lugar
No todos los agentes se benefician. Un agente de navegación abierto, un analizador de mercado en tiempo real, o un bucle de ejecución de código con alta entropía de herramientas no almacenará en caché de manera efectiva. Cada turno obtiene datos diferentes; el prefijo es estático pero el delta es grande. La tasa de acierto se mantiene por debajo del 20% sin importar qué haga. El almacenamiento en caché es un teatro de esfuerzo sin retorno financiero.
La métrica honesta para estos bucles es costo por acción exitosa, no costo por token. Reducir llamadas de herramientas supera al almacenamiento en caché de tokens: una recuperación menos o una decisión de enrutamiento mejor ahorra más que 50k tokens almacenados en caché jamás lo harán. Optimice para menos saltos, mejor selección de acciones, recuperación de fallo más rápida. Si el agente intenta cinco herramientas y una tiene éxito, ha desperdiciado cuatro llamadas de herramientas. Esa es la factura real.
A veces el mejor movimiento es acortamiento de indicación a través de evals, no almacenamiento en caché a través de arquitectura. Ejecute su arnés de eval. Encuentre las características de indicación del sistema que no cambian el resultado. Elimínelas. Una indicación más delgada que factura fresca cada turno aún cuesta menos que una inflada almacenada en caché.
Su próximo movimiento
Implemente una capa de instrumentación simple: registre cache_read_input_tokens, cache_creation_input_tokens, y uncached_input_tokens por turno. Etiquete cada turno con su modo. Calcule la tasa de acierto a nivel de sesión. Obsérvela durante una semana. La forma de los datos le dirá si el almacenamiento en caché es una palanca real o una distracción. Establezca un SLO de tasa de acierto de caché—mínimo 60%—antes de reescribir indicaciones alrededor de puntos de interrupción. Si está viendo colapso a mitad de sesión o tasas de acierto obstinadamente bajas a pesar del contexto estático, no siga ajustando puntos de interrupción; mida costo por acción en su lugar y optimice allí.
Si está depurando regresiones de costo de agente o intentando planificar la migración de GPT-6, podemos ayudar a perfilar esto. Comuníquese si desea hablar sobre la arquitectura de su bucle antes de comprometerse con la instrumentación.