Cómo cambiar las instrucciones de Claude a mitad de una sesión sin tirar la caché: los mensajes de sistema intermedios

El problema: descubres una regla en el turno 40

Cualquiera que haya dirigido una sesión larga con Claude conoce la situación. Tras decenas de turnos, ya con mucho contexto acumulado, aparece una regla nueva que no estaba en el prompt inicial: a partir de ahora, todo el SQL debe escribirse con consultas parametrizadas; o el tono debe pasar a ser formal porque el destinatario ha cambiado. La reacción intuitiva es editar el campo system para añadir la instrucción. Y es exactamente lo que más cuesta, porque la caché de prompts calcula un hash del prefijo de la solicitud en un orden fijo —primero las herramientas, después el sistema, después los mensajes— y exige que ese prefijo coincida byte a byte con una solicitud reciente hasta el punto de corte. Tocar el campo system, aunque sea para añadir una frase, cambia el principio del prompt y provoca un fallo de caché para el sistema y para todos los mensajes cacheados que le siguen.

La técnica: la instrucción va al final, no al principio

La documentación de Anthropic describe la solución con una idea sencilla. En lugar de modificar el campo system de nivel superior, se añade al final del historial un mensaje con rol system, justo en el punto de la conversación en el que la nueva instrucción pasa a ser relevante. Todo lo que había antes queda intacto, así que la entrada de caché existente sigue coincidiendo, y solo el mensaje nuevo se procesa como entrada fresca. Y no es un truco cosmético: según la documentación, un mensaje de sistema intermedio tiene la misma autoridad que el campo system de nivel superior, de modo que Claude lo aplica como instrucción de sistema y no como un texto cualquiera de la persona usuaria. La regla práctica que ofrece Anthropic es clara: el campo system de nivel superior, para lo que debe regir desde el primer turno; un mensaje de sistema intermedio, para lo que solo se vuelve relevante más tarde.

Los casos donde marca la diferencia, y el prompt concreto

El propio ejemplo de la documentación es el de una sesión agéntica larga que necesita una restricción nueva tras decenas de turnos ya cacheados. En una conversación de análisis de datos, el mensaje intermedio podría decir simplemente: «A partir de ahora, escribe todo el SQL con consultas parametrizadas y no concatenes nunca valores en la cadena de la consulta». Ese mensaje se coloca justo antes del siguiente turno de la persona usuaria, sin tocar nada de lo anterior. Otros usos naturales son los cambios de política o de personaje a mitad de sesión, o los recordatorios que dependen de lo que acaba de pasar, como avisar de que un archivo ha cambiado.

Hay una segunda variante para un caso muy concreto: los recordatorios por turno dentro de un bucle de herramientas. Si se inyecta un recordatorio en el historial y se borra en la siguiente solicitud, eso cuenta como editar el historial: la caché falla desde ese punto y, en Claude Fable 5.1 y Claude Mythos 5.1, se invalidan además todos los bloques de pensamiento posteriores. Para eso existe el campo clear_at: con el valor next_user_message, el mensaje de sistema se muestra durante un turno y después permanece en la transcripción ya limpiado, sin consumir tokens de entrada. Esta variante está en beta y requiere la cabecera mid-conversation-system-clear-at-2026-08-21.

La misma lógica se ha extendido a las herramientas, porque el array tools está incluso antes que el campo system en el prefijo, y editarlo invalida la caché de toda la conversación. Con los cambios de herramientas intermedios, se declara el conjunto completo de herramientas desde el principio y se usan bloques tool_addition y tool_removal para ofrecer o retirar una herramienta desde un punto concreto en adelante, sin que el array cambie. Esta parte también es beta, con cabeceras distintas según el caso: inline-tools-2026-09-15 para definir una herramienta dentro de un bloque tool_addition, y mid-conversation-tool-changes-2026-07-01 para cambios que nombran una herramienta por referencia.

Límites que conviene comprobar antes de usarla

El primero es de disponibilidad: según la documentación de caché de prompts, los mensajes de sistema intermedios funcionan en Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5.5, Claude Opus 4.8 y Claude Opus 5, pero no están disponibles en Claude Sonnet 5, donde hay que seguir usando el campo system de nivel superior. El segundo es de coherencia: la propia guía de caché de Anthropic recomienda no cambiar ni las herramientas ni el modelo a mitad de conversación, porque las cachés son específicas de cada modelo, y sugiere que, si hacen falta «modos», en lugar de intercambiar el conjunto de herramientas se le dé a Claude una herramienta que registre la transición de modo, o se pase el modo como contenido de un mensaje. El tercero, más fino: el mensaje intermedio con clear_at no es apto para caché, y poner cache_control en él devuelve un error 400; el punto de corte va en el turno de usuario anterior. Por último, la función es apta para retención cero de datos.

Por qué importa hoy

En sesiones largas con mucho contexto, el coste no está solo en lo que se escribe, sino en lo que deja de leerse desde caché. Si tu integración reconstruye el prompt de sistema cada vez que cambia una regla, es muy probable que estés pagando de nuevo por un prefijo que ya tenías cacheado. El ejercicio práctico es revisar dónde se editan hoy las instrucciones a mitad de sesión, moverlas a mensajes de sistema intermedios en los modelos compatibles, y comparar en la respuesta de la API cuántos tokens se leen desde caché antes y después del cambio.