Tu trabajo cron murió a las 3 de la madrugada. Sin error, sin notificación: el panel del scheduler mostraba que todo estaba en orden, y solo te enteraste a las 9 de la mañana, cuando los datos ya estaban desactualizados. Esto no es hipotético: el 2026-08-14, la propia flota alojada de Hermes se saltó 4 ejecuciones nocturnas consecutivas, y la única pista era un solo WARNING poco llamativo enterrado en un archivo de log. v0.20.3 (tag v2026.8.16.2) es el parche para exactamente esta clase de problema: le enseña a Hermes a detectar sus propios fallos y corregirlos, en lugar de dejarte a ti con el desastre.

La ventana de cambios sumó unos 125 PR y unos 250 commits. Las notas oficiales prometen documentación completa y curada con v0.21.0, pero las partes más valiosas de este parche se explican ya en pocas palabras.

Cron: de «morir en silencio» a «curarse solo»

Empecemos por lo que más duele. El scheduler de Hermes solía tener varias formas de morir «en perfecto estado», y todas podían dejar los trabajos parados durante horas o días mientras el sistema parecía funcionar bien:

• Agotamiento de descriptores de archivo (EMFILE): el ticker interpretaba cualquier error de bloqueo como «el lock lo tiene otro», así que un agotamiento de fd en el archivo de lock se registraba como un tick exitoso — y ningún trabajo volvía a ejecutarse jamás;
• Trabajos atascados: un trabajo que fallaba una sola vez quedaba con su next_run_at aparcado en el futuro, invisible para toda la lógica de limpieza y a prueba de reinicios del gateway;
• Disparos perdidos de providers externos: cuando un cron alojado como Chronos nunca entregaba un disparo, el trabajo quedaba aparcado en el pasado para siempre.

v0.20.3 arregla los tres. El EMFILE ahora se reporta con honestidad y el ticker intenta recuperar descriptores de archivo en la medida de lo posible (backoff exponencial, con un tope de 15 minutos); los trabajos atascados se reactivan automáticamente en el siguiente tick —respetando la expresión cron, así una tarea programada solo para días laborables nunca se ejecutará en sábado—; y los disparos que pierde un provider externo los recupera el gateway localmente después de una ventana de gracia.

La ventana de recuperación es configurable:

cron:
  misfire_grace_minutes: 10   # por defecto 10; 0 o negativo desactiva la recuperación

Igual de importante: las ejecuciones perdidas por fin son visibles. Cada disparo fallido deja una marca last_fire_error en el registro del trabajo, que aparece como una línea roja ⚠ Missed scheduled fire: en hermes cron list, además de en el dashboard y en la salida de la herramienta cronjob list del propio agente; la siguiente ejecución exitosa la borra. En lugar de rebuscar entre logs para saber si un trabajo se ejecutó, ahora basta con:

hermes cron list

Si usas un provider de cron externo (Chronos / cron gestionado alojado), ejecútalo una vez tras actualizar para confirmar que no queda nada pendiente. Para ver el panorama completo de programación, monitorización y comprobaciones previas, consulta nuestra guía completa de automatización con cron.

MCP: soporte del protocolo sin estado de 2026-07-28

En esta ventana también se completó la migración al SDK de MCP 2.x y el soporte de extremo a extremo del protocolo sin estado publicado el 2026-07-28. En palabras llanas: la nueva generación de servidores MCP ya no exige un handshake initialize, y Hermes se conecta a ellos de serie.

Cada servidor MCP puede declarar una clave protocol:

mcp:
  servers:
    my-server:
      url: https://example.com/mcp
      protocol: auto   # auto (por defecto): intenta el handshake heredado y, si falla, usa server/discover

auto no le cuesta ninguna ida y vuelta extra a la flota existente, stateless sondea con discover primero y legacy desactiva el fallback por completo. También se cubren dos detalles de la especificación: las pistas de caché ttlMs/cacheScope que devuelve tools/list alimentan una caché de esquemas con TTL, y el registro OAuth sigue la nueva especificación (con application_type nativo y validación de iss según RFC 9207). Más profundidad sobre configuración de MCP en nuestra guía de variables de contexto de MCP.

Nuevos providers: CommandCode y Muse Spark

Esta ventana añade dos providers:

CommandCode (commandcode.ai) ahora es un provider de primera clase: una sola clave cubre 30+ modelos, abiertos y cerrados, en los planes GOAT/Pro/Max/Provider:

hermes setup   # o configúrala manualmente
export COMMANDCODE_API_KEY="your-key"
hermes --provider commandcode

¿Prefieres la API de Mensajes de Anthropic? El perfil commandcode-anthropic la usa con la misma clave. Y en main (todavía sin entrar en ningún release tag), la Meta Model API (Muse Spark) se suma como plugin integrado: --provider meta-ai funciona de serie con autenticación MODEL_API_KEY (el alias META_API_KEY también funciona), con los modelos muse-spark-1.2 y muse-spark-1.2-contributor.

Botones de deshacer para las ediciones del agente: /worktree y /rollback

Llegan dos comandos inspirados en Copilot CLI para calmar la ansiedad del «el agente me destrozó el repositorio».

/worktree new abre un worktree de git aislado a mitad de sesión, sin necesidad de reiniciar:

/worktree new my-experiment

Hermes crea .worktrees/my-experiment/ dentro del repositorio (la rama parte de la punta del remoto recién obtenida con fetch) y redirige hacia ahí las operaciones de terminal y de archivos de la sesión. Al terminar, el worktree solo se conserva si tiene commits sin publicar, exactamente igual que con hermes -w. /worktree a secas muestra el árbol activo; /worktree list los lista todos.

/rollback ahora usa por defecto una restauración segura: Hermes mantiene un registro por proyecto de cada archivo que escribe (el sha256 de cada escritura aplicada), de modo que un rollback solo revierte los cambios hechos por el agente, borra los archivos creados por el agente y preserva tus ediciones manuales. Pasa --all o --force para restaurarlo todo, y los archivos omitidos se notifican con una pista. Si el agente destrozó un archivo que tú también habías editado a mano, esto es la diferencia entre un rescate y un desastre.

Actualización

hermes update

Después ejecuta hermes doctor para verificar la instalación y reinicia el gateway (hermes gateway). Si usas un provider de cron externo, revisa hermes cron list una vez — asegúrate de que no haya pendientes acumulados.

La lista completa de cambios está en las notas de la versión v0.20.3; los destacados del parche anterior —el registro de conexiones y los deep links de MCP— están en nuestro análisis de v0.20.2.