Wenn ein Agent nicht stoppt.

01 / Die Geschichte

Vier gewünschte Funktionen, fast vier Stunden Hintergrundarbeit

Im Vorfallbericht veröffentlicht auf NautGate am 24. August 2026 ging es zunächst um vier Funktionen für eine kleine Website. Parallel zum sichtbaren Gespräch lief eine Coding-Sitzung im Hintergrund weiter. Nach der ersten Anweisung erhielt keiner ihrer 320 Modellaufrufe einen weiteren menschlichen Prompt.

In fast vier Stunden verbrauchte diese Sitzung 46,55 Millionen neue Eingabetoken. Von den 320 Aufrufen führten 244 zu einem weiteren Werkzeugaufruf. Der aufgezeichnete Verlauf wuchs von 19 Nachrichten auf 662, und die neue Eingabe erreichte schliesslich 273.886 Token bei einem einzigen Aufruf.

Dies war kein Nachweis dafür, dass ein Agent böswillig wurde. Es handelte sich um einen automatisierten Prozess, der über die von uns erwarteten Ressourcengrenzen hinaus weiterlief. Die Grösse der Website stellte keine sinnvolle Grenze für den Arbeitsaufwand dar, den die Sitzung erzeugen konnte.

02 / Das Problem

Eine erfolgreiche Anfrage kann immer noch Teil eines fehlgeschlagenen Workflows sein

Allein die Prüfung auf API-Fehler würde solche Vorfälle übersehen. Ein Modell kann eine gültige Antwort zurückgeben, eine weitere Tool-Aktion anfordern und damit fortfahren. Der einzelne Schritt ist erfolgreich, während der Gesamtauftrag nicht abgeschlossen werden kann.

Mit zunehmender Konversations- und Toolhistorie floss mehr Kontext in nachfolgende Anfragen ein. Wir haben keine entsprechenden Cache-Lesevorgänge beobachtet. Zuvor gesehener Kontext erschien daher wiederholt als neuer Input, wodurch jede Fortsetzung die Inputkapazität verteuerte.

Diese Datensätze zeigen ein Verkehrsmuster, nicht die versteckte Begründung innerhalb der Agentenlaufzeit. Sie beweisen nicht, warum die Hintergrundsitzung fortgesetzt wurde, und belegen auch keinen einzelnen Grund für die fehlende Cache-Wiederverwendung. Bei der Entscheidung, was repariert werden soll, ist die Unterscheidung wichtig.

Betroffen war die gemeinsam genutzte Kapazität. Der veröffentlichte Bericht dokumentiert das Erreichen eines Fünf-Stunden-Limits, einen Beitrag zu einem zweiten Limit und einen starken Rückgang des verfügbaren Wochenkontingents. Auch ohne einzeln abgerechneten API-Aufruf kann eine Anfrage im Abonnement Kapazität verbrauchen, die andere Agenten und ihr Betreiber benötigen.

03 / Was wir gelernt haben

Zeichnen Sie die Sequenz auf und geben Sie dem System dann eine Stoppregel

Verbrauch der jeweiligen Sitzung zuordnen

Die Anfragen wurden über NautGate weitergeleitet, das uns die Quellanwendungs-, Sitzungs-, Timing- und Token-Datensätze lieferte, die zur Rekonstruktion des Laufs erforderlich waren. Wir könnten das Kontextwachstum, das Cache-Verhalten und die gleichzeitige Arbeit untersuchen, anstatt anhand einer Grenzwertbenachrichtigung zu raten.

Diese Sichtbarkeit deckt nur Anfragen ab, die über das Gateway weitergeleitet werden. Ein Tool, das dies umgeht, umgeht auch diese Nachweise und jegliche Durchsetzung zu diesem Zeitpunkt.

Beobachtung und Intervention trennen

Zum Zeitpunkt des Vorfalls konnte das Gateway anzeigen, was passiert war, es fehlte jedoch ein kapazitätsbewusster Schutzschalter für den Abonnementverkehr. Ein Dashboard kann eine Sitzung nicht einfach durch die Anzeige ihres Verbrauchs stoppen.

Ein Schutzmechanismus braucht eine eindeutige Identität, eine prüfbare Regel und eine Stelle, an der er die nächste Anfrage ablehnen kann. Nach Möglichkeit sollte er nur die betroffene Sitzung anhalten. Andere Agenten mit demselben Konto sollen weiterarbeiten können.

Anfrage mit Sitzungskennung trifft ein
  → Nutzung und Verhalten dieser Sitzung prüfen
  → Konfigurierte Regeln auswerten
      → Zulassen und protokollieren
      → Warnen und protokollieren
      → Pausieren, Grund protokollieren und Betreiber benachrichtigen

Dies ist ein konzeptioneller Entscheidungspfad, keine ausführbare NautGate-Konfiguration. Zu den nützlichen Richtlinieneingaben gehören neue Eingaben in einem rollierenden Fenster, Cache-Lese- und -Schreibvorgänge, Anzahl der Anfragen und anhaltende Tool-Aktivität. Eine lange Laufzeit kann legitim sein, daher müssen der erwartete Arbeitsaufwand und die erwarteten Grenzen explizit angegeben werden.

Eine Pause muss die Fallback-Logik überleben

Ein Wechsel zu einem anderen Anbieter löst das Problem nicht zwangsläufig. Dieselbe unkontrollierte Sitzung kann über ein anderes Konto weiterlaufen. Aus erschöpftem Abonnementkontingent können dann nutzungsabhängige Kosten werden.

Der NautGate-Artikel beschreibt Max Guard in v0.5.0 mit Regeln zum Beobachten, Warnen und Pausieren. Er erfasst neue Eingabetokens, Cache-Lesezugriffe und Cache-Schreibvorgänge, Ausgaben und Anfragen. Dazu gehören rollierende Fünf-Stunden- und Wochenfenster. Eine pausierte Max-Anfrage erhält eine nicht wiederholbare Antwort. Sie wechselt nicht stillschweigend zu nutzungsabhängig abgerechneten Anthropic-Credits.

Hier liegt die Grenze des Gateways. Auch die aufrufende Anwendung muss die Ablehnung korrekt behandeln. Wenn der Client eine neue Sitzung startet oder eine ungeschützte Route wählt, kann er die beabsichtigte Pause umgehen.

04 / In die Tat umsetzen

Testen Sie das Stoppverhalten, bevor Sie einen Agenten unbeaufsichtigt lassen

Nutzen Sie für Installation und Konfiguration die aktuelle NautGate-Dokumentation. Der Bericht zu v0.5.0 erläutert die Reaktion auf diesen Vorfall. Welche Einstellungen Ihre Version unterstützt, müssen Sie in deren Dokumentation prüfen.

1. Identifizieren Sie die Anwendung und Sitzung bei jeder Anfrage. Bestätigen Sie, dass der beabsichtigte Datenverkehr tatsächlich das Gateway überquert.
2. Beobachten Sie einen repräsentativen Job. Erfassen Sie das Eingabewachstum, die Cache-Wiederverwendung und die Anzahl der Anfragen, bevor Sie Grenzwerte festlegen.
3. Lösen Sie eine Pause in einem begrenzten Test aus. Prüfen Sie, ob der Client stoppt, der Betreiber eine Erklärung erhält und andere Arbeiten weiterlaufen können.
4. Testen Sie auch den Fallback-Pfad. Eine blockierte Anfrage sollte nicht als automatische Anfrage an einen kostenpflichtigen oder unbewachten Anbieter erneut auftauchen.
5. Definieren Sie, wie die Arbeit fortgesetzt wird. Überprüfen Sie den Sitzungsstatus und die verbleibende Aufgabe, bevor Sie mehr Kapazität genehmigen. Ein Neustart derselben Schleife stellt keine Wiederherstellung dar.

Die Lehre ist nicht, dass jeder Agent mit langer Laufzeit kaputt ist. Der Punkt ist, dass ein kontinuierlicher Strom gültiger Anfragen kein Nachweis für einen nützlichen Fortschritt ist. Wir brauchen Nachweise dafür, was passiert ist, und einen erprobten Weg, um zu stoppen, was nicht weitergehen sollte.