OpenAI mejora el caché de prompts de GPT-6 y añade herramientas para auditar los fallos
La compañía sube el acierto de caché por defecto y mantiene descuentos de hasta el 90% en tokens de entrada reutilizados, pero solo si el prefijo compartido se reusa en una ventana de 30 minutos.
OpenAI ha retocado el sistema de caché de prompts de la familia GPT-6. La compañía dice que ahora acierta más por defecto y que mantiene el descuento de hasta el 90% sobre los tokens de entrada que se sirven desde caché, con una condición que conviene tener apuntada: el prefijo compartido solo es elegible si se reutiliza dentro de una ventana de 30 minutos. El argumento de fondo es el de siempre en este terreno, agentes persistentes que encadenan llamadas a la API durante horas y arrastran las mismas instrucciones, definiciones de herramientas y contexto de turnos anteriores.
Ver qué se cachea y por qué falla
El añadido más práctico es el Prompt Caching Dashboard, que muestra qué parte de la entrada de una aplicación se está sirviendo desde caché. Se puede seguir la tasa de acierto en el tiempo y comparar en un gráfico los tokens cacheados con los que no lo están, útil para detectar caídas y ver cómo afecta cada cambio en el código.
Cuando aparece un fallo inesperado, la herramienta de diagnóstico compara una petición con una respuesta reciente y señala qué cambió para impedir la reutilización: el modelo, las herramientas, los ajustes o la entrada. Devuelve además cuántos tokens se han visto afectados, para dimensionar el problema antes de tocar nada. En el ejemplo que da OpenAI, el motivo es "tools_changed" y el impacto son 5.629 tokens.
Palancas para no romper el caché
La guía de caché de prompts se ha actualizado con los puntos de ruptura explícitos, que permiten decidir qué prefijos se reutilizan, cuánto tiempo siguen siendo elegibles y cómo les afectan los cambios en herramientas y entradas.
Hay tres detalles que afectan a cómo se integra esto. El primero: en los modelos GPT-6 se puede cambiar el esfuerzo de razonamiento entre respuestas sin invalidar la caché, añadiendo un configuration_update y dejando intacto el valor de la petición; se sube para una tarea difícil y se baja para un seguimiento rutinario. El segundo: cuando cambian las necesidades de herramientas del agente, conviene mantener estables las definiciones, los esquemas y su orden, y limitar el alcance con allowed_tools o tool_choice a none en lugar de borrar definiciones. Las instrucciones nuevas se añaden al final del contexto con developer messages, de forma que pisan a las antiguas sin tirar lo anterior. El tercero: prewarming prepara contexto conocido por adelantado, por ejemplo en el arranque de la aplicación, y saca ese procesamiento del tiempo de espera del usuario.
Todo esto importa por una razón muy concreta: en agentes que hacen decenas de llamadas seguidas, la factura y la latencia se deciden en el prefijo compartido, no en cada respuesta. La ventana de 30 minutos es ahora el número que hay que vigilar, y cualquier retoque en el esquema de herramientas puede tirar por la borda el ahorro sin que salte ningún error. Queda por ver si esos controles se comportan igual de bien cuando el agente encadena tareas de horas en lugar de conversaciones cortas.
