Te pasas media hora reescribiendo SOUL.md. Añades dos reglas nuevas a una skill. Reinicias el gateway, vuelves a la sesión que llevaba funcionando desde ayer y le pides que repita la tarea que acaba de hacer. Te contesta con la voz de siempre, sigue los pasos de siempre y evita justo aquello que acababas de pedirle que dejara de evitar. Abres tres veces el archivo de configuración para confirmar que el cambio sí se guardó. Y al final haces lo único que queda: /new, viendo cómo cuarenta turnos de contexto se van al vacío.

La configuración estaba perfecta. Hermes la ignoraba a propósito, para ahorrarte dinero. Ahora hay un comando que refresca las instrucciones sin tocar la conversación.

Por qué una sesión en marcha no ve tu edición

Los provider de modelos tienen un truco para abaratar costes: si el arranque de cada petición es idéntico byte a byte, el proveedor reutiliza el cálculo que ya tiene en caché en lugar de repetirlo. Ese prefijo es el system prompt: el bloque donde viven la persona de SOUL.md, el índice de skills, las reglas de proyecto de AGENTS.md, la memoria y USER.md.

Para mantener ese prefijo estable, Hermes construye el system prompt de cada sesión una sola vez, lo guarda y vuelve a enviar exactamente esos bytes en todos los turnos posteriores. Tras reiniciar el gateway recupera la copia almacenada de la fila de la sesión; y un agente que se mantiene caliente en memoria ni siquiera vuelve a leer los archivos.

Resultado: solo una sesión nueva lee los archivos. Las conversaciones antiguas siguen repitiendo el prompt con el que nacieron, que es justo lo que estabas viendo.

El comando: hermes sessions refresh-prompts

# todas las sesiones de este profile
hermes sessions refresh-prompts

# una sola sesión (id o prefijo único)
hermes sessions refresh-prompts --session a1b2c3

# otro profile distinto
hermes sessions refresh-prompts -p work

# salida legible por máquina, útil dentro de un script de actualización
hermes sessions refresh-prompts --json

Hace muy poco a propósito: apunta una petición de refresco en el state.db del profile e informa de cuántas sesiones tienen un prompt guardado. El trabajo real ocurre al principio del siguiente turno de cada sesión.

La salida se ve así:

Requested a system prompt refresh for every session in this profile (12 session(s) with a stored prompt).
Each rebuilds its prompt from the current SOUL.md, skills and context files on its next turn (one prompt-cache miss per session); conversation history is kept.

Con --session hay un caso límite que ya viene resuelto: una conversación compactada continúa sobre su punta, así que la petición se asocia a esa continuación y no a la raíz original, que quedó cerrada hace tiempo.

Qué se reconstruye realmente

• Se reconstruye: todo el system prompt pasa por el builder habitual, de modo que el SOUL.md nuevo, las skills añadidas o eliminadas, AGENTS.md y los archivos de contexto entran en vigor en ese turno. Los bloques de memoria y USER.md también se releen del disco.
• No se toca: el historial de la conversación, el id de sesión y la lista de herramientas fijada en la sesión. El hook on_session_start no se dispara, así que ninguno de sus efectos secundarios se repite.
• Coste: un fallo de prefix cache por cada sesión refrescada, en el turno que reconstruye. Los turnos siguientes vuelven a estar en caché.
• Persistencia: el prompt nuevo y su sello de versión se escriben de vuelta en state.db y todos los turnos posteriores los reproducen tal cual. Es una reconstrucción puntual, no un gasto por turno.

No hace falta reiniciar el gateway, y reiniciarlo tampoco cancela nada: la petición vive en la base de datos, por lo que un agente que vuelve tras un reinicio la sigue leyendo. Un script de actualización puede invocar el comando antes o después de reemplazar el gateway.

Cómo sabe que toca refrescar

Hermes mantiene una epoch incremental en la tabla state_meta del profile: piensa en ella como el número de revisión de tus instrucciones. Cada sesión anota en su model_config qué revisión cumple ya el prompt que tiene guardado. Al inicio de un turno el agente hace una única lectura puntual: si la epoch guardada es más antigua, reconstruye una vez; si no, no hace nada.

Sin ninguna petición apuntada, el único trabajo extra es esa lectura. Nada vigila archivos en segundo plano y nada cambia las instrucciones a mitad de turno.

Cuándo usarlo — y cuándo no

Qué acabas de cambiar	¿Lanzar refresh-prompts?
SOUL.md, skills, AGENTS.md, USER.md	Sí: es exactamente el caso para el que se creó
Solo el modelo o los parámetros de sampling	No hace falta
Definiciones o permisos de herramientas	Las sesiones nuevas los recogen; en una sesión existente el pin de herramientas se queda como estaba
Quieres empezar de cero con otro tema	Usa /new; este comando no limpia el historial
La fila de la sesión está dañada	Usa hermes sessions repair-prompts, que es otro comando

Dos advertencias. La primera: refrescar no reproduce el historial ni repara una conversación rota, solo sustituye el prefijo de instrucciones. La segunda: si mantienes muchas sesiones largas y pagas por token, prefiere --session, porque cada sesión refrescada paga su propio fallo de caché y con docenas de conversaciones la cuenta sube.

Si tu duda es más bien “por qué se quedan obsoletas las instrucciones después de una compactación”, eso es otro mecanismo: Hermes reconstruye el system prompt al compactar. Lo tienes detallado en cómo la compactación reconstruye el prompt. Si acabas de mover skills al repositorio, lee antes skills locales del proyecto y la puerta de confianza: refrescar es solo la forma en que una sesión viva se pone al día con ellas. Y la mecánica de compartir un único prefix cache entre sesiones está en prefix cache compartida entre profiles. La referencia completa de flags vive en la página del comando hermes sessions.

Estado del release

El comando se integró en main el 29 de octubre de 2026 (PR #143581). El release actual, v0.22.5 (23 de octubre de 2026), todavía no lo incluye: si hermes sessions --help no lista refresh-prompts, estás en una build anterior. Instala desde main para usarlo ya o espera al siguiente release.

Edita los archivos, lanza un comando y el siguiente turno ya corre con las instrucciones nuevas, sin tener que sacrificar una conversación a cambio.