Ochenta y un PRs en una sola etiqueta, y las notas admiten que lo dejaron sin documentar a propósito


Ves la insignia de actualización, haces clic hasta la página de la release y te encuentras un párrafo: esto es una release de parche, empaqueta unos 81 pull requests fusionados desde v0.22.4, y la crónica cuidada sale con v0.23.0. Ninguna lista de cambios, ningún destacado, nada sobre el arreglo que llevas dos semanas esperando. Así que la única pregunta que de verdad importa antes de escribir hermes update es la que queda sin responder: ¿actualizo hoy o espero?

La respuesta corta es que esta etiqueta es un punto de control, no un aluvión de funciones, y el cuerpo de la release sí dice, en una sola línea, que parte de esto queda sin documentar aquí a propósito. Esas líneas omitidas a propósito resultan ser la parte útil, así que este artículo las cubre, junto con los números y la ruta de actualización por plataforma.

Una release de parche es un punto de control, no un aluvión de funciones

Hermes corta dos tipos de release. Las de funciones llevan nombre, secciones y capturas. Las de parche toman todo lo fusionado desde la etiqueta anterior y cortan un nuevo punto estable, para que todos los canales de distribución —la release de GitHub que usan la CLI y el script de instalación, la app de Microsoft Store, Docker y Hermes Cloud— lleven código idéntico. Nada de lo que hay dentro se diseñó para ella; son unos días de trabajo agrupados.

La escala del lote, contada en el commit bf0203a794a:

  • 231 commits no-merge sobre 804 archivos modificados, con +35,212 / −17,885 líneas
  • 81 pull requests fusionados y 30 incidencias cerradas

Ahora compara con v0.22.4, dos días antes: 14 commits no-merge sobre 82 archivos y 13 PRs fusionados, publicada el 21 de octubre. Mismo equipo, mismo canal, seis veces el volumen. Esa comparación es la historia real de esta etiqueta. Lo que se fusionara el día 22 y en las primeras horas del 23 no recibió artículos individuales: se plegó en un rollup.

Un detalle de marcas de tiempo: el cuerpo de la release fecha la publicación el 22 de octubre de 2026, mientras que GitHub publicó la etiqueta a las 05:28 UTC del 23 de octubre. Las dos son correctas: ese momento es la tarde-noche del 22 en California.

Un diff de 35.000 líneas sin lista de funciones no es un diff lleno de funciones: es refactorización, movimientos de plugins, trabajo de dependencias y arreglos pequeños. De eso va el resto del artículo.

Los cuatro cambios que probablemente ya has leído

Cuatro elementos de esta ventana ya tienen su propio artículo aquí. Una línea cada uno, con el enlace por si te los perdiste:

  • El sign-in de Nous se reconstruyó para que todo login sea un device login normal, el resultado te diga quién entró y los conectores ofrezcan iniciar sesión en vez de dejar al visitante en modo invitado. Más en cómo pasa el testigo el sign-in entre app y navegador.
  • Los backends de delegación se volvieron conectables, enrutables por mapeo de modelo o por profile, y cambiables por sesión. El recorrido por el enrutado de backends cubre la configuración.
  • Los planes por usage window se dibujan ahora como barras de progreso y tarjetas de límite en /usage, incluida la recuperación tras cambiar de modelo. Qué significa cada gauge está en el desglose de las usage windows.
  • Las instalaciones de Windows a medio actualizar recibieron un arreglo de verdad en lugar de otra instrucción de reintentar. La historia del launcher explica por qué volver a fijar Python las rompía.

Todo lo que sigue es el resto de los 81.

Lo que las notas dicen haber dejado fuera a propósito

El cuerpo de la release afirma, con esas palabras, que parte de esta ventana queda sin documentar a propósito. Leído con atención, eso no es modestia: estos cambios solo tienen sentido como frases, no como líneas de changelog. Se dividen en tres grupos.

hermes update ahora retiene una release que no va a aceptar

El primer grupo es el comportamiento de actualización, y para quien vive en la CLI es la parte más práctica de la release.

  • Una release estable que Hermes se niega a aceptar ahora se retiene en lugar de ofrecértela. Antes, la comprobación podía mostrar una release como disponible, tú hacías clic y la actualización se negaba. Ese bucle cuesta un clic y, peor, te enseña a desconfiar de la insignia. Ahora la opción simplemente no se presenta.
  • En Windows, hermes update ya no se queda colgado en el launcher viejo después de volver a fijar Python. Volver a fijar cambia qué intérprete debería llamar el launcher; el launcher obsoleto es lo que dejaba instalaciones a medio actualizar.
  • hermes update puede recuperar un gateway suspendido después de que .git se dañe. El elemento menos vistoso y probablemente el que más tardes salva: un repositorio corrupto dejaba el gateway aparcado, y la ruta de reparación ahora lo devuelve en vez de pedirte que arregles git primero.

Los tres van de que el comando de actualización se niega a dejarte en un estado que no puedas razonar. Ninguno añade un flag; cada uno quita una forma de quedarse atascado.

El núcleo sigue adelgazando

El segundo grupo es la migración continuada de funciones integradas a plugins.

hermes import-agent, la migración de OpenClaw, hermes mcp serve y el backend de Singularity salieron todos del núcleo hacia plugins. El setup ahora detecta que ya tienes otro agente instalado y te ofrece el importador, en lugar de dejarte descubrirlo por tu cuenta.

Si actualizas y un comando que usabas la semana pasada ya no está, mira el catálogo de plugins antes de concluir que lo han eliminado. Eso no es nuevo —v0.22.4 movió los mismos comandos—, pero v0.22.5 es donde deja de parecer una limpieza puntual y empieza a parecer la arquitectura.

También en este grupo: los comandos de barra de los plugins ya pueden pedirte que elijas una opción antes de continuar. Un comando que antes corría con comportamiento fijo puede pausar y presentarte una elección. Cambio pequeño en la interfaz, cambio grande en lo que puede ser un plugin: un comando con bifurcación, no solo una macro.

Y un elemento lleva la etiqueta de experimental con honestidad: un cliente de eventos MCP en modo webhook. No construyas un flujo de trabajo sobre él todavía.

Escritorio: arrastra para fijar, insignias y un bot que dice quién trabaja

El tercer grupo es la app de escritorio, donde los cambios son pequeños pero se notan a diario.

  • Arrastrar para fijar en la barra lateral. Las entradas de la barra lateral se pueden arrastrar a una posición fijada en vez de vivir donde la app decida ponerlas.
  • Instalación de plugins en un clic con insignias de nivel. Instalar desde la app es una sola acción, y la insignia dice qué nivel vas a recibir antes de que hagas clic.
  • Electron 44, Pillow 13 y un lote de actualizaciones de seguridad de dependencias. Nada que configurar; la razón para tomarlas es que prefieres no seguir corriendo las versiones viejas.
  • El group chat vuelve a mostrar qué bot está trabajando. Es un arreglo de regresión: con varios bots en una sala, ese indicador es la única forma de saber quién responde, y sin él la sala parece rota en vez de lenta.
  • Una conversación cuyo directorio de trabajo desapareció ahora lo dice con claridad. Los fallos vagos ahí mandan a la gente a auditar el modelo, la red y su prompt antes de que a nadie se le ocurra comprobar si la carpeta sigue existiendo.
  • Las respuestas largas de Claude DirectSDK ya no se cortan por el temporizador de bloqueo. Si algún provider lento te ha truncado una respuesta a media frase, esta es la línea que te importa.

Actualizar, plataforma por plataforma

Dónde ejecutas Hermes Cómo te llega v0.22.5
Instalación por CLI hermes update, o vuelve a ejecutar el one-liner del instalador
App de Microsoft Store a través de la Store
App de escritorio desde el instalador (.exe / .dmg) sin cambios en esta release; se mueve con la siguiente release empaquetada
Docker / Hermes Cloud nousresearch/hermes-agent:stable (o :latest)

La tercera fila es la que la gente malinterpreta: un parche que saca CLI, app de Store, Docker y Cloud no necesariamente reconstruye los bundles .exe y .dmg. Un usuario de escritorio puede ejecutar hermes update, ver la CLI pasar a v0.22.5 y seguir en el build de escritorio anterior: comportamiento correcto, no una actualización fallida.

Cuándo esperar a v0.23.0

Espera si lo que quieres es la historia y no el binario. Las notas cuidadas de toda esta ventana —todo desde v0.22.0, con destacados, funciones agrupadas por área y la lista completa de contribuyentes— salen junto con v0.23.0. Una etiqueta de rollup te dice qué se movió; nunca te dirá por qué alguien lo construyó.

Actualiza ya si alguno de estos es tu problema: una comprobación de actualización que ofrece una release y luego la rechaza, una instalación de Windows atascada en un launcher viejo, un gateway aparcado tras un .git dañado, respuestas largas truncadas en Claude DirectSDK, un group chat que no sabe decirte qué bot trabaja, o una sesión que falla porque su directorio de trabajo se esfumó. Eso no es una lista de funciones. Es un motivo decente para moverse hoy.

Y 81 PRs en dos días sin crónica no es una señal de alarma: es cómo un proyecto a este ritmo mantiene cinco canales de distribución sobre el mismo código. La crónica existe; está programada para la próxima release de funciones.