Conoces esa sensación: le pides a Hermes una tarea de verdad grande — refactorizar todo el repositorio, procesar miles de archivos por lotes, montar un pipeline de datos de principio a fin — y está trabajando sin descanso, cuando de repente se detiene. No es un error. No es una pregunta. Simplemente… termina. La mitad de la tarea está hecha y el resto se queda ahí.

Eso no era magia, era un límite por defecto estricto que Hermes solía tener: dentro de un mismo turno, el agent podía llamar a herramientas como máximo 500 veces. Quinientas suena a mucho, pero cualquier tarea real — buscar, leer código, editar archivos, ejecutar tests, corregir errores, volver a ejecutar tests — las gasta en un momento. Y lo peor: se detenía en silencio. Solo te dabas cuenta del trabajo a medias cuando volvías a repasar la conversación.

Ese límite por defecto ha desaparecido: a partir de la rama main (post-v0.20.4), agent.max_turns es ilimitado por defecto. Esta entrada explica qué cambió, por qué y cómo fijar un tope cuando de verdad lo quieres.

Primero: qué es exactamente max_turns

max_turns (también llamado max iterations) limita cuántas veces puede el agent llamar a herramientas dentro de un turno — no cuántos turnos puedes tener. Piénsalo así: envías un mensaje, Hermes se pone a trabajar, y cada archivo que lee, cada comando que ejecuta, cada llamada a la API cuenta como una iteración. max_turns: 500 significaba: en este turno puede hacer como máximo 500 unidades de trabajo, y después debe detenerse y devolverte el control.

En las versiones antiguas el valor por defecto era 500. De sobra para el día a día de preguntas y respuestas, pero para tareas que necesitan «leer el código → cambiar decenas de archivos → ejecutar tests → corregir → volver a ejecutar», 500 era un techo invisible. La tarea chocaba con el límite a mitad de camino y los pasos restantes tenían que esperar a un «continue» manual.

Y podía ser peor: si escribías max_turns: none en tu config para expresar «sin límite», el código antiguo fallaba con un TypeError (issue #82813) — o ignoraba el valor en silencio. A veces no fallaba con elegancia: podía tumbar los cron jobs y el gateway.

El nuevo valor por defecto: ilimitado, salvo que fijes un tope

Este cambio (PR #90708) invierte por completo el comportamiento por defecto:

Ajuste	Antes	Ahora
Sin fijar (por defecto)	limitado a 500	ilimitado
max_turns: none	crash con TypeError	ilimitado
max_turns: null / unlimited / inf / infinity / 0 / -1	crash o ignorado	ilimitado
max_turns: 200	limitado a 200	limitado a 200 (sin cambios)

En otras palabras: por defecto, una tarea ahora llega hasta el final — se acabaron los cortes silenciosos. Todas las formas de escribir «ilimitado» (none, null, unlimited, infinite, infinity, inf, ∞, 0, -1, sin distinguir mayúsculas de minúsculas y tolerante con los espacios) son ahora ciudadanos de primera clase, normalizadas por una única función resolve_turn_limit(). Escribe la que prefieras — mismo resultado y sin crashes.

Si de verdad quieres un tope para algunas tareas, un entero positivo sigue funcionando exactamente igual que antes.

Cómo fijar un límite cuando lo necesitas

Lo ilimitado es el valor por defecto, pero no es lo adecuado para todos los escenarios — por ejemplo, un cron job que se ejecuta cada hora y del que quieres que haga una cantidad acotada de trabajo para que no pueda gastar una fortuna sin querer. Hay tres formas de fijar un tope (de menor a mayor precedencia):

1. Archivo de configuración (config.yaml)

agent:
  max_turns: 200   # como máximo 200 llamadas a herramientas por turno

2. CLI

hermes config set agent.max_turns 200

3. Variable de entorno

export HERMES_MAX_ITERATIONS=200
hermes chat

Las tres pasan por el mismo parser resolve_turn_limit(), así que el comportamiento es consistente pongas el valor donde lo pongas.

No lo confundas: goals.max_turns se mantiene en 20

Una cosa que no cambió: goals.max_turns mantiene su valor por defecto de 20.

agent.max_turns gobierna los turnos de conversación normales; goals.max_turns gobierna el modo goal (le das a Hermes un objetivo a largo plazo y lo dejas trabajar de forma autónoma hasta terminar) — concretamente, cuántos ciclos de auto-continuación puede ejecutar. El modo goal tiene su propia protección de presupuesto: se pausa tras 20 continuaciones y te pide que hagas /goal resume o que lo limpies, para que un objetivo difuso no pueda quemar dinero indefinidamente. El PR dejó ese campo deliberadamente intacto — cada uno de los dos ajustes cumple su función.

En resumen: ¿quieres que las tareas largas dejen de cortarse? Usa el valor ilimitado por defecto (no hay nada que configurar). ¿Quieres un freno para la persecución autónoma de objetivos? Ajusta goals.max_turns.

Vale la pena saberlo ahora que es ilimitado

Con los turnos ilimitados, hay dos cosas que conviene tener presentes:

• Conciencia del coste: la tarea se ejecuta hasta el final, lo que significa que sigue llamando a la API del modelo. Si te importa el gasto, no confíes en max_turns como freno — usa herramientas más precisas como agent.run_budget_seconds (un presupuesto de tiempo real que te avisa al llegar al 80% del tiempo transcurrido) o el idle timeout del gateway (que solo salta cuando el agent ha estado completamente inactivo durante un rato). Son «frenos elegantes» — mucho más agradables que detenerse a mitad de tarea.
• cron y gateway también salen ganando: como el scheduler de cron y la configuración del gateway ahora comparten el mismo resolver, el viejo crash al escribir none en la config de cron también está arreglado. Las tareas cron largas ahora se ejecutan hasta el final en una sola pasada.

Resumen

Que agent.max_turns pase de «500 por defecto» a «ilimitado por defecto» es un arreglo pragmático para la experiencia con tareas largas: deja que las tareas que deberían terminar, terminen; y que quienes quieren límites, los fijen. El cambio está ahora en la rama main (fusionado después de v0.20.4) — cuando salga la próxima versión oficial, un simple hermes update te lo trae.

¿Quieres profundizar en cómo maneja Hermes los turnos y el contexto? Echa un vistazo a nuestro análisis en profundidad sobre el manejo de errores y recuperación, o a la guía de configuración para tareas largas con ajustes prácticos que evitan que las tareas se queden atascadas.