Loop-Engineering mit drei Agenten: Was yetones Magpie-Workflow über das unbeaufsichtigte Ausführen von Claude Opus 5.5 aussagt

Das Interessanteste an yetones Setup ist nicht das Modell. Es ist die Zahl drei. Der Maintainer von Magpie – ein lokales Gateway, mit dem Coding-Agents gegen jedes Modell laufen können, auf das man sie richtet – beschrieb am 2026-10-13 auf X seinen eigenen Wartungs-Workflow: Claude Code, angetrieben von Anthropics Claude Opus 5.5, wobei drei /loopAufgaben gleichzeitig liefen, jede von ihnen überwachte eine andere Oberfläche – GitHub-Issues und Pull Requests, die Discord-Community und Feedback, das auf X eintraf – und behob, was sie fand. Loop-Engineering, die Praxis, einen Agenten in einem Zyklus weiterlaufen zu lassen, statt ihn Runde für Runde zu prompten, war in diesem Jahr Gegenstand vieler Gespräche. Was dieses Beispiel lesenswert macht, ist, dass es mit einem Organigramm daherkommt.

Claude Opus 5.5 ist nicht neu. A​nthropic hat es am 22.09.2026 ausgeliefert, vor drei Wochen, für 4 $ pro Million Input-Tokens und 20 $ pro Million Output-Tokens. Das ist keine Launch-Story. Es ist eine Geschichte darüber, was die Defaults des Modells für alle bedeuten, die versuchen, eine Wartungsschleife mit drei Agenten nachzubauen – und darüber, welche Teile dieser Schleife auf Weisen brechen, die in den Tutorials nicht erwähnt werden.

Was ist tatsächlich im Workflow enthalten?

Das Signal ist kurz, deshalb lohnt es sich, präzise zu sein: was behauptet wird und was nicht. Doch /loopyetone führt drei gleichzeitige Aufgaben in Claude Code auf Opus 5.5 aus. Einer beobachtet das Repository – Issues und Pull Requests. Einer beobachtet Discord. Einer beobachtet X. Der Agent behebt, was er für behebungswert hält, im Loop, ohne dass ein Mensch jeden Durchlauf anstößt. Das Muster, das er automatisiert hat, ist das, was die meisten Maintainer schlecht machen: Triage. Nicht das Programmieren. Das Lesen, Sortieren, Deduplizieren und Beantworten, das eine Stunde am Tag frisst.

Der Ausdruck Loop-Engineering ist hier tragend. Ein Loop ist kein Agent, der eine Aufgabe erledigt; er ist eine Sitzung, die immer wieder zu einer Aufgabe zurückkehrt – nach einem Zeitplan, den sie selbst bestimmt, wobei der Zustand der letzten Iteration noch vor ihr liegt. Diese Unterscheidung ist der Punkt, an dem die meisten selbstgebauten Versionen auseinanderfallen, und genau dorthin hat sich das Tooling in den vergangenen sechs Wochen bewegt.

Was Claude Codes /loop im Oktober 2026 tatsächlich macht

Wenn Sie die aktuelle Dokumentation nicht gelesen haben, ist die Version, an die Sie sich erinnern, wahrscheinlich falsch, weil /loop eine andere Form bekommen hat, während Loop-Engineering im Trend lag.

Ein bloßes /loop verlangt nicht mehr, dass du ein Intervall angibst. Lass es weg, und Claude wählt dynamisch eines aus – zwischen einer Minute und einer Stunde – basierend darauf, was Claude in der vorherigen Iteration beobachtet hat. Claude wartet kurz, während ein Build fertig wird oder ein Pull Request aktiv ist, und wartet viel länger, wenn nichts ansteht. Die gewählte Verzögerung und der Grund dafür werden am Ende jeder Iteration ausgegeben, sodass du die eigene Überlegung des Loops zu seinem Takt sehen kannst. Gib stattdessen ein Intervall an — /loop 5m check the deploy — und du erhältst einen festen Cron-Zeitplan.

Wenn Sie den Prompt ebenfalls weglassen, erhalten Sie einen integrierten Wartungs-Prompt, der bei jeder Iteration drei Dinge der Reihe nach abarbeitet:

• Setzen Sie alle unerledigten Arbeiten aus der Unterhaltung fort.

• Kümmere dich um den Pull Request des aktuellen Branches — Review-Kommentare, fehlgeschlagene CI-Läufe, Merge-Konflikte.

• Führe Aufräumdurchläufe wie Fehlersuchen oder Vereinfachungen durch, wenn nichts anderes ansteht.

Du kannst diese Standardvorgabe durch deine eigenen Anweisungen ersetzen. Schreibe dazu eine loop.md – in .claude/loop.md für ein Projekt oder ~/.claude/loop.md für jedes Projekt, das keine eigene definiert. Änderungen werden bei der nächsten Iteration wirksam, sodass du die Anweisungen einer laufenden Schleife verfeinern kannst, ohne sie neu zu starten. Die Datei wird nach 25.000 Bytes abgeschnitten, was mehr als genug Platz für Triage-Regeln bietet.

Dieser Mechanismus ist der tragende Teil eines Drei-Schleifen-Aufbaus, und er ist der Teil, den Workflow-Diagramme normalerweise auslassen. Ein generischer integrierter Wartungs-Prompt ist keine Triage-Richtlinie. Wenn du eine Schleife willst, die GitHub-Issues so liest, wie dein Projekt GitHub-Issues liest – was als Duplikat zählt, was ein Label statt einer Antwort bekommt, was niemals eine Antwort bekommt –, muss die Richtlinie in loop.md liegen, nicht in dem Prompt, den du eingegeben hast, als du die Sitzung gestartet hast.

Die Grenzen, die entscheiden, ob drei eine Zahl oder ein Slogan ist

Drei gleichzeitige Schleifen sind der Punkt, an dem die Einschränkungen zu greifen beginnen, und es lohnt sich, sie aufzulisten, bevor du jemandes Setup kopierst.

• Parallelitätsobergrenze — eine Sitzung hält bis zu 50 geplante Aufgaben gleichzeitig, drei Schleifen sind also weit von dieser Grenze entfernt. Der entscheidende limitierende Faktor ist nicht die Anzahl der Aufgaben, sondern die Aufmerksamkeit: Drei Schleifen bedeuten drei Ströme von Tool-Aufrufen, die um dieselbe Sitzung konkurrieren.

• Ablauf — wiederkehrende Aufgaben löschen sich sieben Tage nach ihrer Erstellung selbst und werden beim Verschwinden noch ein letztes Mal ausgelöst. Eine Wartungsschleife, die am achten Tag still zum Erliegen kam, ist der mit Abstand häufigste Ausfallmodus, und sie versagt lautlos.

• Asymmetrien wiederherstellen — setze eine Sitzung mit --resume oder --continue fort, und cron-geplante Aufgaben kommen zurück, außer den wiederkehrenden, die abgelaufen sind. Eine selbstgesteuerte Schleife wird überhaupt nicht wiederhergestellt; du musst sie erneut starten.

• Verhalten bei ausgelasteter Sitzung — Eine Aufgabe wird zwischen Turns ausgelöst, niemals mitten in einer Antwort. Wenn ein langer agentischer Turn läuft, während eine Schleife fällig wird, wartet die Auslösung. Verpasste Intervalle summieren sich nicht; sie fallen zu einer einzigen Auslösung zusammen.

• Jitter – wiederkehrende Aufgaben werden absichtlich verzögert ausgeführt, um bis zur Hälfte des Abstands zum nächsten Lauf und höchstens 30 Minuten, damit eine Flotte von Sitzungen nicht auf derselben Sekunde zusammenläuft. Eine Aufgabe im Zehn-Minuten-Takt startet irgendwo zwischen pünktlich und fünf Minuten zu spät. Der Fünf-Minuten-Fall ist die Ausnahme: Claude Code verschiebt ihn um 15 Sekunden nach vorne, damit jeder Lauf innerhalb des Prompt-Cache-Fensters bleibt.

• Erfordernis „Rechner muss eingeschaltet sein“ — Schleifen werden nur ausgelöst, solange Claude Code läuft und im Leerlauf ist. Das Zuklappen des Laptops stoppt sie. Für die Stunden, in denen Sie abwesend waren, gibt es kein Nachholen.

Das Letzte ist der Grund, warum dieser Workflow das Setup eines Maintainers ist und nicht das eines Platform-Teams. Drei Loops auf einer Maschine, in einer Sitzung, sind eine Möglichkeit, ein stark frequentiertes Open-Source-Projekt am Laufen zu halten, während man etwas anderes tut; es ist kein Service.

Warum dieser Workflow spezifisch für Claude Opus 5.5 ist und nicht nur „ein Agent“

Betreibt man eine Schleife aus drei Agenten gegen ein Modell ohne großes Kontextfenster, verbringen diese Schleifen ihren Tag damit, immer wieder dasselbe zu lesen. Jede Iteration liest den Issue-Thread, den PR-Diff und den Discord-Verlauf erneut ein; ist das Fenster klein, wird dieser Verlauf weggzusammengefasst, und das Urteilsvermögen der Schleife verschlechtert sich still und leise, je älter die Sitzung wird. Claude Opus 5.5 bringt ein Kontextfenster von 1 Mio. Tokens bei 128K Tokens Ausgabe mit – genau das ermöglicht es einer Triage-Schleife, einen echten Issue-Backlog plus eine Konversation plus die letzten paar Iterationen gleichzeitig zu halten. Es kostet außerdem $4 / $20 pro Million Tokens, und Cache-Lesevorgänge kosten $0,20 pro Million – ein Fünftel des Eingabepreises –, was hier mehr als sonst zählt, denn eine Schleife ist die cache-freundlichste Arbeitslast überhaupt. Derselbe System-Prompt, dieselben Tool-Definitionen, derselbe Repo-Kontext, immer und immer wieder.

Die zweite Anpassung ist der Standard für das Denken, und sie wirkt sich je nachdem, was jede Schleife tut, in die andere Richtung aus. Claude Opus 5.5 betreibt adaptives Denken immer aktiv, wobei der Aufwand standardmäßig auf mittel steht – eine Stufe unter dem Standard von Claude Opus 5. Der Aufwand verändert nicht nur die Qualität; er verändert auch das Volumen der Tool-Aufrufe. Eine Schleife, die Issues triagiert, und eine, die Code bearbeitet, brauchen unterschiedliche Einstellungen, und die Einstellung mit dem geringsten Aufwand ist außerdem ein eigenes Scheduling-Problem: Bei einer selbstgetakteten Schleife wählt das Modell seine eigene Verzögerung bis zum nächsten Aufwachen, sodass sich eine Triage-Schleife mit geringem Aufwand und eine Fixing-Schleife mit hohem Aufwand gegenüber demselben Repository unterschiedlich takten. Es gibt keine Einstellung, die sie zur Übereinstimmung bringt. Der Punkt ist, zu wissen, welche die eine und welche die andere ist, denn der Unterschied in der Taktung ist das, was du zuerst sehen wirst.

Wenn du den Loop und den Fixer gegen die Modelle verschiedener Anbieter laufen lassen willst — Triage auf etwas Günstigem, Fixes auf Claude Opus 5.5 —, dann ist das eher eine Routing- als eine Claude-Code-Entscheidung, und das ist der Grund, warum ein Gateway vor der Sitzung sitzt.

Das auszuprobieren, ohne die Produktion dafür aufs Spiel zu setzen.

Der berechtigte Einwand gegen ein Setup mit drei Schleifen ist, dass es einen autonomen Agenten schon am ersten Nachmittag vor die Issues deiner Nutzer setzt. Die Schleife wird kommentieren. Sie wird Dinge schließen. Der ehrliche Weg, das einzuführen, ist, eine Schleife eine Woche lang im Dry-Run-Modus mit einem schreibgeschützten GitHub-Token laufen zu lassen und zu sehen, ob ihre Triage-Urteile mit denen übereinstimmen, die du von Hand gefällt hast — und, getrennt davon, das Modell selbst dorthin zu leiten, wo du es messen kannst, bevor du dich festlegst.

Auf OrcaRouter wird anthropic/claude-opus-5.5 zum Listenpreis von Anthropic ohne Aufschlag angeboten, von einem einzigen Endpunkt, der sowohl die OpenAI-kompatiblen als auch die Anthropic-Messages-Formate spricht – sodass eine Claude-Code-Sitzung und ein Skript, das mit demselben Modell kommuniziert, keine zwei Integrationen benötigen. Anthropic hat am 22.09.2026 seine eigenen Preise von $4 / $20 veröffentlicht; wenn sich dieser Listenpreis ändert, ändert sich ein Pass-through-Gateway am selben Tag mit, statt erst im nächsten Abrechnungszyklus, was die Variante ist, die man will, wenn man eine Schleife dimensioniert, die monatelang laufen könnte. Automatisches Failover über Anbieter hinweg deckt den Fall ab, vor dem die Dokumentation warnt und den niemand testet: Die Schleife stoppt nicht, weil ein Upstream um drei Uhr morgens eine 429 zurückgegeben hat. Modell-Fusion und die Routing-DSL spielen hier eine geringere Rolle – eine Triage-Schleife will ein Modell, konsequent, weil Konsistenz das ist, was ihre Beurteilungen überprüfbar macht.

Was man mit der Zahl Drei machen kann

Das Reputationsproblem von Loop-Engineering ist, dass das meiste, was in diesem Jahr demonstriert wurde, eine einzige Schleife war, die eine einzige eng umrissene Aufgabe in einer Demo ausführte. Das Setup von yetone ist interessant, weil es drei Schleifen über drei verschiedene Eingaben sind – das Repository, die Chat-Community, die öffentliche Timeline –, was der Form der eigentlichen Aufgabe entspricht, für die ein Maintainer keine Zeit hat. Es ist auch die Form, die jede der oben genannten Einschränkungen offenlegt: Ablauf, Jitter, Wiederherstellung, Taktung und die Tatsache, dass die Schleifen nur laufen, solange die Maschine eingeschaltet ist.

Der übertragbare Teil ist nicht die Anzahl. Es ist, dass jede Schleife ihre eigene Oberfläche, ihre eigene Richtlinie in loop.md und ihren eigenen Grund zum Aufwachen bekam – und dass die Person, die sie laufen ließ, aus dem Iterationsprotokoll erkennen konnte, warum jede Schleife die Verzögerung wählte, die sie wählte. Das ist ein Setup, das man tatsächlich eine Woche später auditieren kann. Was, da jede dieser Schleifen am achten Tag abläuft, ungefähr die Zeit ist, die man hat, um zu entscheiden, ob man es wieder aufbaut.

Um es klar zu sagen: Dies ist das Setup eines einzelnen Praktikers, das sein Autor auf X beschrieben hat, keine vom Anbieter empfohlene Vorgehensweise. Die Dokumentation von Anthropic für Claude Opus 5.5 und Claude Codes /loop beschreibt, was die Tools tun. Sie sagt aber nicht, dass drei die richtige Zahl ist, und das tut auch sonst noch niemand.

Wenn die Triage-Schleife und die Korrektur-Schleife unterschiedliche Modelle wollen: Betreibe die Schleife und den Fixer über einen einzigen Endpunkt bietet Claude Opus 5.5 zum Listenpreis von A​nthropic über einen einzigen Endpunkt, der sowohl das OpenAI-kompatible als auch das Anthropic-Messages-Format spricht.

Modellentscheidungen wie diese sind auch der Punkt, an dem die Fehlermodi auftauchen: Die dokumentierten KI-Vorfälle und Agentenausfälle hinter Modellen dieser Klasse sind gesammelt in dem OrcaRouter AI Incident Archive, wo jeder Eintrag eigene Quellen, Schweregrad, Konfidenzstufe und eine Kennzeichnung als umstritten enthält.