Du kennst das Gefühl: Du bittest Hermes um eine richtig große Aufgabe – das ganze Repo umbauen, tausende Dateien in einem Rutsch verarbeiten, eine Data Pipeline von A bis Z aufbauen – und es arbeitet vor sich hin, dann stoppt es plötzlich. Kein Fehler. Keine Rückfrage. Einfach … fertig. Die halbe Aufgabe ist erledigt, der Rest bleibt liegen.

Das war keine Magie, sondern eine feste Standard-Obergrenze, die Hermes früher hatte: Innerhalb eines einzigen Turns durfte der agent höchstens 500-mal Tools aufrufen. Fünfhundert klingt nach viel, aber jede echte Aufgabe – suchen, Code lesen, Dateien ändern, Tests laufen lassen, Bugs fixen, Tests nochmal laufen lassen – verbraucht das schneller, als man denkt. Schlimmer noch: Es stoppte still. Die halb fertige Arbeit ist dir erst aufgefallen, als du in der Konversation zurückgescrollt hast.

Diese Standardeinstellung ist weg: Seit dem main-Branch (nach v0.20.4) ist agent.max_turns standardmäßig unbegrenzt. Dieser Beitrag erklärt, was sich geändert hat, warum, und wie du ein Limit setzt, wenn du tatsächlich eines willst.

Zuerst: Was max_turns wirklich ist

max_turns (auch max iterations genannt) begrenzt, wie oft der agent innerhalb eines Turns Tools aufrufen darf – nicht, wie viele Turns du haben kannst. Stell es dir so vor: Du schickst eine Nachricht, Hermes beginnt zu arbeiten, und jede Datei, die es liest, jeder Befehl, den es ausführt, jeder API-Aufruf, den es macht, zählt als eine Iteration. max_turns: 500 bedeutete: In diesem Turn darf es höchstens 500 Arbeitseinheiten erledigen, dann muss es stoppen und die Kontrolle an dich zurückgeben.

In den alten Versionen war der Standardwert 500. Für den Alltag mit Fragen und Antworten reicht das locker, aber bei Aufgaben, die „Codebase lesen → dutzende Dateien ändern → Tests laufen lassen → fixen → nochmal laufen lassen“ erfordern, war 500 eine unsichtbare Decke. Die Aufgabe stieß mitten in der Arbeit an die Grenze, und die restlichen Schritte mussten auf ein manuelles „weiter“ warten.

Und es kam schlimmer: Wer in seiner Config max_turns: none schrieb, um „kein Limit“ auszudrücken, bekam in alten Versionen einen Absturz mit TypeError (issue #82813) – oder der Wert wurde stillschweigend ignoriert. Manchmal scheiterte es nicht einmal elegant: Es konnte cron-Jobs und den gateway mitreißen.

Der neue Standard: unbegrenzt – außer du wählst ein Limit

Diese Änderung (PR #90708) dreht das Standardverhalten komplett um:

Einstellung	Vorher	Jetzt
Nicht gesetzt (Standard)	auf 500 begrenzt	unbegrenzt
max_turns: none	TypeError-Absturz	unbegrenzt
max_turns: null / unlimited / inf / infinity / 0 / -1	Absturz oder ignoriert	unbegrenzt
max_turns: 200	auf 200 begrenzt	auf 200 begrenzt (unverändert)

Anders gesagt: Eine Aufgabe läuft jetzt standardmäßig bis zum Ende durch – kein stiller Abbruch mehr. Jede Schreibweise für „unbegrenzt“ (none, null, unlimited, infinite, infinity, inf, ∞, 0, -1 – Groß-/Kleinschreibung egal, Leerzeichen werden toleriert) ist jetzt ein vollwertiger Wert und wird von einer einzigen Funktion, resolve_turn_limit(), normalisiert. Schreib, was dir gefällt – gleiches Ergebnis, keine Abstürze.

Wenn du für bestimmte Aufgaben wirklich ein Limit willst: Eine positive ganze Zahl funktioniert weiterhin exakt wie vorher.

So setzt du ein Limit, wenn du eines willst

Unbegrenzt ist der Standard, aber nicht für jedes Szenario die richtige Wahl – etwa bei einem cron-Job, der stündlich läuft und den du auf eine begrenzte Menge Arbeit beschränken willst, damit er nicht versehentlich ein Vermögen verbraucht. Es gibt drei Möglichkeiten, ein Limit zu setzen (von niedrigster zu höchster Priorität):

1. Config-Datei (config.yaml)

agent:
  max_turns: 200   # höchstens 200 Tool-Aufrufe pro Turn

2. CLI

hermes config set agent.max_turns 200

3. Umgebungsvariable

export HERMES_MAX_ITERATIONS=200
hermes chat

Alle drei Wege laufen durch denselben resolve_turn_limit()-Parser, das Verhalten ist also konsistent, egal wo du das Limit setzt.

Nicht verwechseln: goals.max_turns bleibt bei 20

Eines hat sich nicht geändert: goals.max_turns behält seinen Standardwert von 20.

agent.max_turns regelt normale Konversations-Turns; goals.max_turns regelt den goal mode (du gibst Hermes ein langfristiges Ziel und lässt es autonom weiterarbeiten, bis es fertig ist) – genauer gesagt, wie viele Auto-Continue-Zyklen er laufen darf. Der goal mode hat einen eigenen Budgetschutz: Er pausiert nach 20 Fortsetzungen und fragt dich, ob du mit /goal resume weitermachen oder abbrechen willst – so kann ein vages Ziel nicht endlos Geld verbrennen. Der PR hat dieses Feld bewusst in Ruhe gelassen – die beiden Einstellungen erledigen jeweils ihren eigenen Job.

Also: Sollen lange Aufgaben nicht mehr abgeschnitten werden? Nutze den unbegrenzten Standard (nichts zu konfigurieren). Willst du eine Bremse für die autonome Zielverfolgung? Dann stimme goals.max_turns darauf ab.

Wissenswert, jetzt wo es unbegrenzt ist

Beim unbegrenzten Turn sind zwei Dinge im Hinterkopf zu behalten:

• Kostenbewusstsein: Die Aufgabe läuft bis zum Ende durch, das heißt, sie ruft weiterhin die Modell-API auf. Wenn dir die Kosten wichtig sind, verlass dich nicht auf max_turns als Bremse – nutze präzisere Werkzeuge wie agent.run_budget_seconds (ein Zeitbudget, das dich bei 80 % der verstrichenen Zeit warnt) oder den Idle-Timeout des gateways (greift nur, wenn der agent eine Weile komplett untätig war). Das sind „sanfte Bremsen“ – deutlich angenehmer als ein Stopp mitten in der Aufgabe.
• Auch cron und gateway profitieren: Weil der cron-Scheduler und die gateway-Config jetzt denselben Resolver nutzen, ist auch der alte Absturz behoben, wenn in der cron-Config none stand. Lange cron-Aufgaben laufen jetzt in einem Durchgang bis zum Ende.

Zusammenfassung

Dass agent.max_turns von „Standard 500“ auf „Standard unbegrenzt“ umgestellt wurde, ist ein pragmatischer Fix für lange Aufgaben: Aufgaben, die fertig werden sollen, dürfen fertig werden; wer Limits will, kann Limits setzen. Die Änderung liegt derzeit auf dem main-Branch (nach v0.20.4 gemerged) – sobald das nächste offizielle Release erscheint, bringt dich ein einfaches hermes update dorthin.

Mehr darüber, wie Hermes Turns und Kontext handhabt? Wirf einen Blick auf unseren Deep Dive zu Fehlerbehandlung und Recovery oder den Config-Guide für lange Aufgaben mit praktischen Einstellungen, die verhindern, dass Aufgaben hängen bleiben.