die schnelle antwort
- Was eine Agent-Schleife ist: ein Zyklus aus bewerten, Werkzeuge aufrufen, Ergebnisse zurückbekommen, erneut entscheiden. Ein Durchgang heißt Runde. Die Schleife endet, wenn der Agent ohne Werkzeugaufruf antwortet.
- Was sie von Prompten unterscheidet: nicht du prüfst jeden Zwischenschritt, sondern der Agent prüft gegen ein messbares Ziel.
- Was sie zähmt: ein Erfolgskriterium, eine Rundengrenze, ein Kostendeckel. Bei mir sind das drei Runden, danach wird gefragt.
Die meisten arbeiten mit KI im Kreis. Prompt eingeben, Ergebnis ansehen, Prompt nachschärfen, wieder eingeben. Das Ergebnis wird besser, dein Vormittag ist weg.
Ich baue seit Monaten täglich mit Claude Code: Websites, Server, Auswertungen, Beratungsprojekte. Der Sprung kam nicht durch bessere Formulierungen. Er kam, als ich aufgehört habe, jeden Schritt selbst zu beauftragen, und stattdessen Schleifen gebaut habe, die ein Ziel kennen und sich selbst prüfen. Dieser Beitrag zeigt, wie so eine Schleife innen aussieht, welche Arten es gibt, und wo die Grenzen hingehören, damit aus Autonomie keine offene Rechnung wird.
eine runde der agent-schleife
der agent geht vier schritte, immer in dieser reihenfolge. nach der dritten erfolglosen runde hält er an und fragt.
bewegung zeigt die reihenfolge. ohne bewegung stehen alle vier schritte mit ziffern da.
der prompt-kreislauf und sein preis
Im klassischen Ablauf bist du die Prüfinstanz. Du liest jedes Ergebnis, entscheidest, ob es passt, und formulierst den nächsten Versuch. Jede Runde kostet dich Aufmerksamkeit, und deine Aufmerksamkeit ist der Engpass, nicht das Modell.
Eine Agent-Schleife verschiebt genau diese Prüfung. Du beschreibst einmal, was fertig heißt. Der Agent arbeitet, prüft sein Ergebnis gegen diese Bedingung und arbeitet weiter, bis sie erfüllt ist. Du kommst erst wieder ins Spiel, wenn das Ergebnis vorliegt oder eine Grenze greift.
| prompt-kreislauf | agent-schleife | |
|---|---|---|
| wer prüft das ergebnis | du, nach jedem versuch | der agent, gegen ein messbares kriterium |
| wann ist schluss | wenn du zufrieden bist | wenn das kriterium erfüllt ist oder eine grenze greift |
| was du lieferst | jeden nächsten arbeitsschritt | ziel, prüfbefehl, grenzen |
| engpass | deine aufmerksamkeit | kontext und kontingent |
was in einer runde passiert
Der Zyklus ist bei jedem Agenten derselbe, ob im Terminal oder eingebaut in eine eigene Anwendung über das Agent SDK. Fünf Phasen, immer in dieser Reihenfolge.
auftrag aufnehmen
Der Agent bekommt Prompt, Systemanweisung, Werkzeugliste und den bisherigen Verlauf.
bewerten
Er entscheidet: mit Text antworten, Werkzeuge aufrufen oder beides.
werkzeuge ausführen
Lesende Werkzeuge laufen parallel, schreibende nacheinander. Ergebnisse gehen zurück.
wiederholen
Bewerten und Ausführen bilden eine Runde. Runden laufen ohne dich weiter.
ergebnis liefern
Eine Antwort ohne Werkzeugaufruf beendet die Schleife. Dazu kommen Kosten und Verbrauch.
Wichtig für das Verständnis: Eine Runde ist ein Hin und Her. Das Modell erzeugt eine Ausgabe mit Werkzeugaufrufen, die Werkzeuge laufen, die Ergebnisse gehen automatisch zurück. Das passiert ohne dich. Erst wenn eine Ausgabe keinen Werkzeugaufruf mehr enthält, endet die Schleife und liefert das Ergebnis.
Mehrere Werkzeuge in einer Runde laufen teils gleichzeitig. Lesende Werkzeuge dürfen parallel arbeiten, weil sie nichts verändern. Werkzeuge, die schreiben oder Befehle ausführen, laufen nacheinander, damit sie sich nicht in die Quere kommen. Das ist der Grund, warum eine Recherche über viele Dateien schnell fühlt und eine Reihe von Änderungen nicht.
eine echte sitzung, runde für runde
Ein Beispiel aus meinem Alltag, verkürzt: Ein Anfrageformular nahm E-Mail-Adressen ohne Punkt in der Domain an. Auftrag an den Agenten war nicht finde den Fehler, sondern schreibe einen Test, der den Fehler zeigt, dann mach ihn grün.
| runde | was der agent tut | was zurückkommt |
|---|---|---|
| runde 1 | testlauf starten | ein neuer test schlägt fehl, wie gewünscht |
| runde 2 | dateien lesen | die prüfung der domain fehlt in der validierung |
| runde 3 | datei ändern, testlauf starten | alle tests grün, nur die genannte datei geändert |
| abschluss | kein werkzeug | kurze meldung mit stand, kosten und verbrauch |
Vier Runden, drei davon mit Werkzeugaufrufen, eine als Abschluss in Text. Genau so zählt auch die Grenze max_turns: Sie zählt die Runden mit Werkzeugnutzung. Stünde sie hier auf zwei, hätte die Schleife vor der Änderung gestoppt und den Ergebnistyp error_max_turns gemeldet.
die begriffe in einem block
Über Schleifen wird meist auf Englisch geschrieben. Die Begriffe tauchen in jeder Dokumentation und in jedem Befehl auf, deshalb hier einmal sortiert, mit der deutschen Bedeutung daneben.
| begriff | was gemeint ist | wo du ihm begegnest |
|---|---|---|
| agentic loop | die agent-schleife selbst: bewerten, werkzeuge aufrufen, erneut entscheiden | dokumentation, blogbeiträge, produktseiten |
| turn | eine runde, also ein hin und her aus modellausgabe und werkzeugergebnis | die grenze max_turns zählt genau diese runden |
| goal | die prüfbare bedingung, die die schleife beendet | befehl /goal, dazu ein bewertungsmodell, das die bedingung prüft |
| loop und schedule | wiederholung nach zeit, in der sitzung oder ohne offene sitzung | befehle /loop und /schedule |
| subagent | unterauftrag mit eigenem, leerem kontext, gibt nur sein ergebnis zurück | orchestrierung, kostenkontrolle, lange recherchen |
| compaction | automatisches zusammenfassen des älteren verlaufs, wenn der platz knapp wird | systemnachricht compact_boundary im nachrichtenstrom |
| hook | kleines programm an einem haltepunkt der schleife, kann werkzeuge blocken | vor und nach werkzeugaufrufen, beim abschluss, vor der komprimierung |
| effort | anstrengungsgrad, also wie tief das modell je antwort denkt | einstellung je sitzung oder je unterauftrag |
Zwei Begriffe werden dabei oft verwechselt. Ein Loop ist der Mechanismus, also das Wiederholen selbst. Ein Goal ist die Bedingung, die den Loop beendet. Ein Loop ohne Goal läuft, bis Geld oder Geduld ausgehen. Ein Goal ohne Loop ist nur ein guter Vorsatz.
vier arten von schleifen
Nicht jede Schleife wird von dir gestartet, und nicht jede endet, wenn das Modell zufrieden ist. Vier Bauformen deckt der Alltag ab.
| art | auslöser | ende | geeignet für |
|---|---|---|---|
| rundenbasiert | dein prompt | wenn das modell sich für fertig hält | kurze, einmalige aufgaben |
| zielgesteuert | /goal mit prüfbarer bedingung | wenn die bedingung erfüllt oder die rundenzahl erreicht ist | aufgaben mit messbarem ergebnis |
| zeitgesteuert | /loop oder /schedule in festen abständen | abbruch durch dich oder erledigte aufgabe | wiederkehrende arbeit, überwachung |
| proaktiv | ereignis, etwa ein neuer fehlerbericht | läuft, bis du sie abschaltest | gleichartige ströme: triage, updates, migrationen |
Der Unterschied zwischen zielgesteuert und rundenbasiert ist der wichtigste Hebel. Rundenbasiert hört der Agent auf, wenn er meint, fertig zu sein. Zielgesteuert hört er auf, wenn ein Prüfschritt bestätigt, dass er fertig ist. Dazwischen liegt der Unterschied zwischen einem Vorschlag und einem Ergebnis.
Am weitesten weg vom Schreibtisch steht die proaktive Form. Sie startet ohne dich und meldet sich erst, wenn etwas zu entscheiden ist.
ein lauf, der ohne dich startet
ein zeitplan oder ein ereignis stößt die schleife an. der agent arbeitet und prüft sich selbst. zurück kommt ein vorschlag, entschieden wird von dir.
der goldene punkt ist die arbeit. am agenten dreht er eine weile, das sind die runden.
die befehle: /goal, /loop, /schedule
Drei Befehle machen aus dem Dialog eine Schleife. Sie sind schnell erklärt und werden trotzdem selten genutzt.
/goal hält die Schleife offen, bis eine Bedingung erfüllt ist. Du formulierst die Bedingung als Satz, den eine Maschine entscheiden kann. Bei jedem Versuch aufzuhören prüft ein kleines Bewertungsmodell diese Bedingung und schickt die Arbeit zurück, wenn sie nicht stimmt. Ein Beispiel, so wie ich es eingebe:
/goal alle Tests in tests/ laufen grün, geändert wurde nur src/validation.ts, höchstens drei Korrekturrunden, danach Stand melden und fragen
Der letzte Halbsatz ist der wichtige. Ohne Rundengrenze läuft die Prüfschleife weiter, solange sie noch eine Idee hat.
/loop wiederholt eine Aufgabe in festen Abständen. Mit Intervall arbeitet er nach der Uhr, ohne Intervall taktet das Modell selbst und wartet so lange, wie es beim beobachteten Vorgang sinnvoll ist. Zwei Beispiele aus dem Alltag:
/loop 30m prüfe den Deploy-Status der Seite, melde nur Änderungen /loop fünf Durchläufe am Textentwurf, jeder Durchlauf schärft eine Schwachstelle
/schedule legt Läufe an, die ohne offene Sitzung starten. Das ist die Form für den Montagmorgen-Bericht oder die nächtliche Prüfung. Damit verlässt die Schleife deinen Schreibtisch, und genau deshalb gehören dort feste Grenzen und ein klarer Meldeweg dazu.
| befehl | was er macht | so sieht ein auftrag aus |
|---|---|---|
| /goal | hält die schleife offen, bis eine prüfbare bedingung erfüllt ist | alle tests in tests/ grün, nur src/validation.ts geändert, höchstens drei runden |
| /loop | wiederholt eine aufgabe in der sitzung, mit oder ohne festes intervall | /loop 30m deploy-status prüfen, nur änderungen melden |
| /schedule | legt läufe an, die ohne offene sitzung starten | montags 7 uhr bericht über die woche, abbruch nach drei erfolglosen läufen |
In meiner Konfiguration steht für alle drei dieselbe Regel: Ziel, Prüfbefehl und Abbruch nach drei erfolglosen Durchläufen gehören in den Auftrag. Ein zeitgesteuerter Lauf ohne Abbruch ist kein Helfer, sondern ein Abonnement.
das erfolgskriterium
Eine Schleife ohne messbares Ziel ist ein Kostenrisiko. Die Regel, die bei mir in der globalen Konfiguration steht, lautet deshalb: Vor dem ersten Schritt wird das Erfolgskriterium als Prüfbefehl formuliert. Was muss grün sein, was heißt fertig. Ohne Kriterium kein Loop.
| so sagt man es | so kann eine maschine es entscheiden |
|---|---|
| baue eine validierung ein | tests für ungültige eingaben vorhanden und grün |
| behebe den fehler | test reproduziert den fehler, danach grün |
| mach die seite schneller | größter inhaltsblock unter 2,5 sekunden im messlauf |
| räum den code auf | verhalten unverändert, testlauf grün, nur genannte dateien berührt |
Der Trick ist die Übersetzung von Absicht in Prüfbarkeit. Baue eine Validierung ein wird zu es gibt Tests für ungültige Eingaben, und die laufen grün. Behebe den Fehler wird zu es gibt einen Test, der den Fehler reproduziert, und der ist danach grün. Beides kann eine Maschine entscheiden. Genau darum kann die Schleife laufen, ohne dass du daneben sitzt.
warum meine grenze bei drei runden liegt
Autonomie ohne Grenze wird teuer, und zwar doppelt. Erstens wächst der Kontext mit jeder Runde, also steigen die Kosten pro Runde. Zweitens dreht ein Agent, der eine falsche Annahme trägt, diese Annahme immer schneller im Kreis.
Deshalb steht in meiner Konfiguration eine harte Obergrenze: drei Runden, je Schritt und je Ziel. Nach der dritten erfolglosen Runde hält der Agent an und nennt drei Dinge in je einer Zeile: aktueller Stand, Befund, beste Option. Danach entscheide ich. Nicht weiterraten, nicht still weiterdrehen.
| Kategorie | Wert |
|---|---|
| runde 1 | 8 |
| runde 2 | 16 |
| runde 3 | 24 |
| runde 4 | 32 |
| runde 5 | 40 |
| grenze bei drei runden | 24 |
- runde 18
- runde 216
- runde 324
- runde 432
- runde 540
- grenze bei drei runden24
Rechenbeispiel, keine Messung: Angenommen, jede Runde legt 8.000 Token Werkzeugergebnisse und Antworten oben drauf. Dann bezahlt Runde 5 den gesamten Verlauf der Runden 1 bis 4 mit. Der Effekt ist der Grund für Rundengrenzen, nicht die Rechenleistung einer einzelnen Antwort.
Die technischen Gegenstücke dazu heißen im SDK max_turns für die Rundenzahl und max_budget_usd für den Kostendeckel. Der Deckel gilt inklusive Unteraufträge: Deren Ausgaben zählen mit, und ist er erreicht, startet kein weiterer Unterauftrag mehr. Für zeitgesteuerte Schleifen gilt bei mir dieselbe Drei: Nach drei erfolglosen Durchläufen meldet sich der Agent, statt bis zum nächsten Monatsende zu tickern.
orchestrieren statt alles selbst tippen
Der zweite Teil meiner Loop-Regel ist ein Routing. Planen, Prüfen und Abnehmen macht das stärkste Modell. Mechanische Arbeit geht an kleine, günstige Helfer, jeder in seinem eigenen Kontext. Unabhängige Schritte starten gemeinsam, nicht hintereinander.
| schritt | wer macht ihn | warum dort |
|---|---|---|
| ziel, plan, abnahme | stärkstes modell | hier entscheidet urteil, nicht tempo |
| kleinteilige änderung | unter-helfer auf kleinem modell | eigener kontext, günstiges kontingent |
| mechanik ab zwei dateien | externer helfer mit eigenem kontingent | umbenennen, gerüstcode, tests, doku |
| review und zweite diagnose | zweites werkzeug, anderes modell | ein prüfer, der den eigenen plan nicht kennt |
| suche über viele dateien | lesender unterauftrag | nur das ergebnis landet im hauptgespräch |
Der Nebeneffekt ist wichtiger als die Ersparnis pro Aufruf: Ein Unterauftrag startet mit leerem Gesprächsverlauf und gibt nur sein Ergebnis zurück. Das Hauptgespräch wächst also um eine Zusammenfassung, nicht um das ganze Protokoll. Deshalb sind Unteraufträge das stärkste Mittel gegen aufgeblähten Kontext, und nicht bloß eine Sparmaßnahme.
Dazu gehört auch Ehrlichkeit über Grenzen. Fällt ein Helfer zweimal am selben Schritt durch, übernimmt die nächste Stufe. Ist ein Kontingent leer, wechselt die Schleife den Pool und läuft weiter. Ein Agent, der wartet, ist genauso wertlos wie einer, der rät.
das kontextfenster, der stille kostentreiber
Alles, was der Agent weiß, liegt in einem Fenster: Systemanweisung, Werkzeugbeschreibungen, deine Regeldateien, der Gesprächsverlauf, jede Werkzeugeingabe und jedes Werkzeugergebnis. Zwischen Runden wird dieses Fenster nicht geleert. Es wächst.
was in einer anfrage mitreist
jede anfrage trägt den kern und alle schichten darum. kern, werkzeuge und regeldateien bleiben gleich groß und werden zwischengespeichert. nur die äußere schicht wächst mit jeder runde, und sie ist die teure.
ein unterauftrag startet mit leerem verlauf. deshalb hält er den äußeren ring des hauptgesprächs klein.
Das Fenster hat zwei Seiten. Gleichbleibende Teile wie Systemanweisung, Werkzeugbeschreibungen und Regeldateien werden zwischengespeichert, kosten also nur beim ersten Aufruf voll. Wachsende Teile wie Werkzeugergebnisse nicht. Eine einzige große Datei zu lesen kann eine Runde teurer machen als zehn gezielte Suchen.
Läuft das Fenster voll, komprimiert der Agent selbst: Älterer Verlauf wird zusammengefasst, das Neueste bleibt. Im Nachrichtenstrom erscheint dafür ein Eintrag vom Typ compact_boundary. Praktische Folge: Was dauerhaft gelten soll, gehört nicht in den ersten Prompt, sondern in eine Regeldatei, die bei jeder Anfrage erneut mitgeht.
Bei diesen Regeldateien lohnt der Blick auf die eigene Rechnung. Auf meiner Maschine lagen in jeder Sitzung drei Regeldateien gleichzeitig im Kontext, die sich zu rund 60 Prozent überschnitten. Ich habe sie am 21.09.2026 entdoppelt: von 46.235 auf 16.512 Bytes, also 64 Prozent weniger Sockel bei identischen Regeln. Gemessen mit wc -c vorher und nachher.
| Kategorie | Wert |
|---|---|
| vorher, drei dateien | 46.235 |
| nachher, entdoppelt | 16.512 |
- vorher, drei dateien46.235
- nachher, entdoppelt16.512
Eigene Messung vom 21.09.2026. Drei Dateien vorher: globale Regeldatei 17.408 Bytes, Projektdatei 13.318 Bytes, eine vollständige Kopie mit 15.509 Bytes. Nachher: 14.552 Bytes plus 1.960 Bytes, die Kopie stillgelegt. Regelinhalt unverändert, geprüft über Marker-Abgleich in beiden Fassungen.
die stellschrauben im überblick
Vier Einstellungen entscheiden, wie selbstständig und wie teuer eine Schleife läuft. Sie sind in der Oberfläche unterschiedlich benannt, meinen aber dasselbe.
| stellschraube | was sie begrenzt | standard ohne einstellung |
|---|---|---|
| rundengrenze | zählt runden mit werkzeugnutzung, stoppt danach | ohne grenze, bis das modell fertig ist |
| kostendeckel | stoppt bei einem betrag, unteraufträge zählen mit | ohne deckel |
| anstrengungsgrad | wie tief das modell denkt, von niedrig bis maximal | wird selbst bestimmt |
| berechtigungsmodus | was ohne rückfrage laufen darf, von plan bis alles erlaubt | rückfrage bei allem, was eingreift |
Zum Anstrengungsgrad ein Hinweis aus der Praxis: Niedrig ist nicht schlechter, sondern billiger für einfache Arbeit. Dateien auflisten braucht keine tiefe Analyse. Ein Umbau an einer Bezahlfunktion schon. Der Grad lässt sich für die ganze Sitzung setzen und je Unterauftrag überschreiben.
Bei den Berechtigungen lohnt Vorsicht in der einen Richtung und Mut in der anderen. Für lange, langweilige Arbeit in einem abgetrennten Ordner spart der Modus, der Dateiänderungen automatisch freigibt, viele Rückfragen. Den Modus, der alle Prüfungen überspringt, gehört in Container und Testumgebungen, nicht auf die Maschine mit deinen Kundendaten.
hooks: die schleife anhalten, bevor etwas passiert
Hooks sind kleine Programme, die an festen Punkten der Schleife anspringen: vor einem Werkzeugaufruf, danach, beim Abschluss, vor der Komprimierung. Sie laufen außerhalb des Modellkontexts, kosten also keine Token, und können einen Werkzeugaufruf verhindern.
| haltepunkt | wann er anspringt | wofür in der praxis |
|---|---|---|
| vor dem werkzeugaufruf | bevor gelesen, geschrieben oder ausgeführt wird | gefährliche befehle blocken, eingaben prüfen |
| nach dem werkzeugaufruf | sobald das ergebnis zurückkommt | ausgabe prüfen, folgeschritt auslösen |
| beim abschluss | wenn der agent fertig meldet | ergebnis gegen das kriterium prüfen, stand sichern |
| vor der komprimierung | wenn das kontextfenster knapp wird | vollständiges protokoll archivieren |
Bei mir arbeiten drei davon täglich. Ein Hook sperrt Schreibzugriffe auf Dateien mit Zugangsdaten, unabhängig davon, wie plausibel der Auftrag klingt. Ein zweiter erinnert das Hauptmodell daran, mechanische Schritte an den günstigen Helfer zu geben, statt alles selbst zu tippen; er blockiert nie, er protokolliert nur. Ein dritter spiegelt Regeländerungen automatisch auf den Server, sobald die Quelldatei bearbeitet wird.
Der dritte Hook lieferte am 21.09.2026 gleich eine Lehre: Er hängt am Werkzeugaufruf, nicht an der Datei. Weil ich die Regeldatei über ein Skript geändert hatte, sprang er nicht an, und der Server lief zwei Stunden mit dem alten Stand. Sichtbar wurde das erst über den Soll-Ist-Abgleich der Prüfsummen. Merke: Ein Hook ist eine Zusage über einen Weg, nicht über ein Ergebnis.
abnahme mit gegenprobe
Ein grüner Prüfbefehl beweist wenig, solange niemand geprüft hat, ob er überhaupt rot werden kann. Deshalb endet jede Schleife bei mir mit derselben Kette.
prüfbefehl grün
Der Agent meldet fertig, die Prüfung läuft ohne Fehler durch.
absichtlich kaputt
Eine Stelle wird bewusst falsch gemacht, die für das Ergebnis zählt.
muss rot werden
Bleibt die Prüfung grün, prüft sie das Falsche. Dann war das grün wertlos.
zurücknehmen, alles erneut
Änderung rückgängig, dann jeden Prüfbefehl noch einmal. Ein späterer Schritt kann einen früheren zurückdrehen.
Das klingt nach Umstand und hat mir mehrfach falsche Erfolgsmeldungen erspart. Ein Beispiel vom 18.09.2026: Eine Prüfung meldete grün, weil sie eine Zeichenkette im Quelltext fand. Ausgeliefert wurde die Seite aber ohne Wirkung, weil die Zeile an einem Anführungszeichen abbrach. Der Textfund war echt, die Wirkung nicht. Seitdem gilt: Prüfe das Ergebnis, nicht die Absicht, und mach die Prüfung einmal absichtlich kaputt.
wie du morgen anfängst
Du brauchst kein Framework und keine Agentenplattform, um den Unterschied zu spüren. Drei Schritte reichen.
- Ziel statt Auftrag formulieren. Schreibe hin, was fertig heißt, in einem Satz, prüfbar. Erst danach beschreibst du die Aufgabe.
- Grenzen setzen. Eine Rundenzahl und ein Kostendeckel, bevor du startest. Bei mir sind es drei Runden, danach eine Rückfrage.
- Arbeit verteilen. Planen und Prüfen beim starken Modell, Tipparbeit beim günstigen Helfer, Review bei einem zweiten Werkzeug. Unabhängiges parallel starten.
Wie die Einrichtung darunter aussieht, von der Regeldatei über das Modell-Routing bis zum Gedächtnis über Sitzungen, steht im Beitrag Claude Code einrichten.
Und dann das Wichtigste: einmal bewusst nicht eingreifen. Die meisten brechen ihre erste Schleife nach zwei Minuten ab, weil der Agent einen Weg nimmt, den sie selbst nicht genommen hätten. Warte auf das Ergebnis und bewerte es gegen dein Kriterium, nicht gegen deinen Plan.
kostenloser leitfaden
Claude Code richtig einrichten. 31 Seiten, 11 Teile, von der Installation bis zum eigenen Autopiloten, mit allen Befehlen und Regeln zum Kopieren. Du bekommst ihn nach der Anmeldung zu meinem Newsletter CLARITY, abmelden geht jederzeit mit einem Klick.
stand der angaben
technische angaben: Ablauf der Schleife, Nachrichtentypen, Optionen für Runden, Budget und Anstrengungsgrad, Berechtigungsmodi, Komprimierung und Hooks nach der Dokumentation von Anthropic, Seite „So funktioniert die Agent-Schleife“ auf code.claude.com, abgerufen am 21.09.2026. Die vier Schleifenarten nach dem Beitrag „Loop engineering“ im Blog von claude.com, abgerufen am 21.09.2026. Die Durchsetzung des Budgetdeckels über Unteraufträge setzt laut Dokumentation Claude Code ab Version 2.1.217 voraus.
eigene messungen: Regelsockel dreier Dateien 46.235 auf 16.512 Bytes am 21.09.2026, gemessen mit wc -c. Sitzungssockel 73.356 auf 16.972 Token am 10.09.2026, Median über 1.031 Sitzungen. Zwei A/B-Läufe am 17. und 18.09.2026 zu Kompressionswerkzeugen: 2,5 Prozent und rund 11 Prozent teurer als der Lauf ohne. Wissensgraph eines großen Projekts am 20.09.2026: 23.185 Dateien, 326.311 Knoten, 549.887 Kanten, rund 21 Minuten Bauzeit ohne Modellaufruf. Ein Werkzeugserver für Schwarm-Orchestrierung meldete 353 Werkzeuge mit zusammen rund 76.000 Token Beschreibung, gemessen am 20.09.2026. Alle Werte stammen von meiner Arbeitsmaschine und können in anderen Einrichtungen abweichen.
häufige fragen
was ist eine agent-schleife?
Eine Agent-Schleife ist der Arbeitszyklus eines KI-Agenten: Er bewertet die Lage, ruft Werkzeuge auf, bekommt die Ergebnisse zurück und entscheidet erneut. Dieser Zyklus wiederholt sich, bis der Agent eine Antwort ohne Werkzeugaufruf gibt. Ein solcher Durchgang heißt Runde.
was ist der unterschied zwischen prompten und einer schleife?
Beim Prompten prüfst du jedes Ergebnis selbst und startest den nächsten Versuch. In einer Schleife übernimmt das der Agent: Er kennt das Erfolgskriterium, prüft sein Ergebnis dagegen und arbeitet weiter, bis es erfüllt ist oder eine Grenze greift. Du bewertest das Ergebnis, nicht jeden Zwischenschritt.
wie verhindere ich, dass eine ki-schleife endlos läuft?
Mit einem messbaren Erfolgskriterium, einer Rundengrenze und einem Kostendeckel. Im Agent SDK heißen die Grenzen max_turns und max_budget_usd. Wird eine erreicht, endet der Lauf mit error_max_turns oder error_max_budget_usd. In meiner Konfiguration stoppt der Agent zusätzlich nach drei erfolglosen Runden am selben Ziel und fragt.
was gehört in ein gutes erfolgskriterium?
Etwas Messbares, das ohne Meinung entschieden werden kann. Gut: alle Tests grün, nur die genannten Dateien geändert, Antwortzeit unter 200 Millisekunden. Schlecht: sieht besser aus, fühlt sich schneller an. Ohne messbares Kriterium ist eine Schleife nur ein teurer Zufallsgenerator.
welche arten von schleifen gibt es?
Vier: rundenbasiert im normalen Dialog, zielgesteuert über /goal mit prüfbarer Abbruchbedingung, zeitgesteuert über /loop oder /schedule in festen Abständen, und proaktiv, ausgelöst durch Ereignisse, ohne dass jemand daneben sitzt.
wie starte ich eine zielgesteuerte schleife mit /goal?
Du rufst /goal auf und schreibst die Abbruchbedingung als prüfbaren Satz, etwa: alle Tests im Ordner tests/ laufen grün, geändert wurde nur src/validation.ts. Bei jedem Versuch aufzuhören prüft ein kleines Bewertungsmodell die Bedingung und schickt die Arbeit zurück, bis sie stimmt oder die Rundenzahl erreicht ist.
wofür ist /loop gut und wofür /schedule?
/loop wiederholt eine Aufgabe in der laufenden Sitzung, mit Intervall wie /loop 30m oder ohne Angabe, dann taktet das Modell selbst. /schedule legt wiederkehrende Läufe an, die auch ohne offene Sitzung starten. Beide brauchen Ziel, Prüfbefehl und Abbruch.
warum sollte ein agent mehrere modelle nutzen?
Weil Planen und Prüfen anspruchsvoll sind, Tippen aber nicht. Das starke Modell setzt das Ziel, plant und nimmt ab. Kleine Modelle führen mechanische Schritte in eigenen Unteraufträgen aus. Das hält das Hauptgespräch schlank und belastet das teure Kontingent nur dort, wo es etwas bringt.
was passiert, wenn das kontextfenster voll wird?
Der Agent komprimiert automatisch: Älterer Verlauf wird zusammengefasst, die neuesten Austausche bleiben. Im Nachrichtenstrom erscheint dafür eine Systemnachricht vom Typ compact_boundary. Anweisungen aus dem frühen Gespräch können verloren gehen, deshalb gehören Dauerregeln in eine Regeldatei statt in den ersten Prompt.
sind schleifen teurer als einzelne prompts?
Pro Lauf meist ja, pro Ergebnis oft nein. Eine Schleife arbeitet ohne deine Wartezeit weiter, braucht dafür aber Kontext, der mit jeder Runde wächst. Rundengrenze, Kostendeckel und Modell-Routing halten das im Rahmen.