Con las lecturas de caché de Fable 5.1 a 0,25 dólares por millón de tokens, lo caro ya no es leer la caché: es perderla. Cada invalidación convierte un prefijo que costaba una décima parte en tokens de entrada a precio completo, y en una sesión agéntica larga eso se nota en la factura antes que en el reloj. Las notas de la API del 1 de septiembre traen dos betas dedicadas exactamente a eso: cambiar cosas a mitad de conversación sin tirar lo que ya estaba cacheado.
Son los mensajes de sistema de un solo turno y el effort por mensaje. Resuelven dos problemas distintos con la misma idea de fondo.
Editar el system prompt te cuesta la conversación entera
Para entender qué resuelven hay que recordar cómo se forma el prefijo cacheado. El orden es siempre tools → system → messages, y un cambio en cualquier nivel invalida ese nivel y todos los posteriores. Tocar las definiciones de herramientas tira la caché entera; tocar el campo system de nivel superior tira todo lo que venga después.
Ahí está el problema práctico que cualquiera que haya montado un agente conoce: las instrucciones que descubres que necesitas a mitad de la sesión. Un recordatorio de formato, un cambio de tono, una restricción que solo aplica a partir de cierto punto. El sitio natural para ponerlas es el system, y el system está al principio de todo. Escribir ahí una instrucción que se te ocurre en el turno quince significa reprocesar los quince turnos.
La alternativa que usaba casi todo el mundo era colar la instrucción como texto de usuario, que no invalida nada pero tampoco se comporta como una instrucción de sistema. Los mensajes de sistema a mitad de conversación cerraron ese hueco: se añade un mensaje con role: "system" en el punto donde la instrucción pasa a ser relevante, el prefijo cacheado se queda igual y la instrucción sigue aplicándose como lo que es.
Un recordatorio que se ve una vez y después no cuesta nada
La primera de las dos betas afina eso. Un mensaje de sistema a mitad de conversación admite ahora el campo clear_at, con dos valores posibles: "never", que es el comportamiento de siempre, y "next_user_message", que lo convierte en un mensaje de un solo turno. Requiere la cabecera de beta mid-conversation-system-clear-at-2026-08-21; sin ella, clear_at se rechaza como campo desconocido.
El funcionamiento es elegante. El texto se renderiza solo mientras no haya después ningún mensaje de usuario. En cuanto aparece uno, el mensaje queda limpiado: sigue en el array, pero no renderiza nada y no cuesta tokens de entrada, ni en esa petición ni en ninguna posterior. Un detalle a tener en cuenta: un mensaje de usuario que solo lleva bloques tool_result cuenta como mensaje de usuario a estos efectos.
El caso de uso que la documentación pone es el que le da sentido: un harness que empuja al modelo después de cada tanda de resultados de herramientas —»agrupa las lecturas independientes», «hace rato que el usuario no sabe nada de ti»— y que quiere que vea solo la copia más reciente. Hasta ahora, esos recordatorios se acumulaban turno tras turno, pagándose enteros en cada petición y compitiendo entre sí por la atención del modelo. Ahora se apagan solos sin borrar nada del historial.
El mensaje no se borra: deja de renderizar y deja de costar. El historial permanece intacto.
Cambiar de marcha a mitad de tarea
La segunda beta ataca otro gasto silencioso. Un mensaje role: "system" puede llevar ahora output_config.effort para cambiar el nivel de esfuerzo a partir del siguiente turno de usuario, conservando la caché. Está en beta sobre Claude Fable 5.1, Claude Mythos 5.1 y Claude Opus 5 en la API de Claude, con la cabecera mid-conversation-output-config-2026-07-01.
La utilidad es directa para cualquier agente con fases: exploración inicial que pide razonamiento alto, ejecución mecánica posterior que no lo necesita. Antes, bajar el esfuerzo a mitad implicaba cambiar parámetros de la petición, y los parámetros de pensamiento están entre los que invalidan la caché de mensajes. Ahora el cambio viaja dentro de messages, como un mensaje más, sin tocar el prefijo.
🔧 Las dos no van en el mismo mensaje
Un mensaje de un solo turno solo admite bloques de texto. Meterle output_config devuelve un 400, igual que los bloques de adición o eliminación de herramientas. Si quieres un recordatorio efímero y además un cambio de effort, van en dos mensajes role: "system" separados: el del effort, sin clear_at.
Las reglas que rompen el truco si las ignoras
Esta es la parte que conviene leer despacio, porque son restricciones cuyo incumplimiento devuelve justo lo que intentabas evitar. La primera y más importante: los mensajes ya limpiados hay que reenviarlos literalmente. Siguen formando parte del historial, y reconstruirlos desde el estado actual —con un recuento de tokens fresco, con una marca de tiempo nueva—, descartarlos por redundantes o cambiarles el valor de clear_at cuenta como editar un mensaje anterior. La caché falla desde ese punto y, en Fable 5.1, todos los bloques de pensamiento posteriores fallan la comprobación de conversación.
La segunda: no se puede poner cache_control en sus bloques. Un mensaje limpiado nunca forma parte de una clave de caché, así que un punto de ruptura ahí no podría coincidir jamás. El breakpoint va en el último bloque del turno de usuario anterior. El campo de caché automática, por su parte, ya salta estos mensajes cuando elige dónde poner el corte.
Y la tercera, de colocación: un mensaje de este tipo debe ir después de un turno de usuario —o de uno de asistente que termine en resultado de herramienta de servidor— y antes de un turno de asistente, o cerrando el array. Uno seguido directamente de otro mensaje de usuario no se limpia: devuelve un 400. La forma correcta es meter todos los resultados de una ronda de herramientas en un único mensaje de usuario y poner los recordatorios detrás.
Merece la pena el detalle de qué se reprocesa exactamente en la petición que limpia un mensaje: el prefijo cacheado reutilizable termina en el turno de usuario anterior, de modo que lo único que se vuelve a procesar es el turno de asistente que queda en medio. Eso es lo que hace que el mecanismo salga a cuenta.
Cómo saber si te está funcionando
Todo esto es invisible hasta que lo mides, y el sitio donde mirar es el bloque usage de la respuesta. cache_read_input_tokens dice cuántos tokens se leyeron de la caché, cache_creation_input_tokens cuántos se escribieron y input_tokens cuántos quedaron fuera del corte. La señal de alarma es la de siempre: si los dos primeros son cero, no estás cacheando nada, y toca buscar el invalidador.
Para quien no construya agentes propios y trabaje con n8n o con Claude Code, la aplicación es indirecta pero real: estas dos betas son las piezas que permiten a un harness inyectar instrucciones y ajustar el esfuerzo sin que la sesión larga se encarezca. Es decir, la infraestructura que hace que las herramientas que ya usas dejen de tirar la caché por detrás. Si mantienes integraciones propias contra la API, en cambio, es material accionable hoy mismo: los recordatorios acumulados y los cambios de parámetros a mitad de sesión son dos de las causas más comunes de una factura que no cuadra con lo que creías estar gastando.
