Loop-engineering hos Three Agents: Vad yetones Magpie Workflow säger om att köra Claude Opus 5.5 obevakat

Det mest intressanta med yetones uppsättning är inte modellen. Det är siffran tre. Underhållaren av Magpie – en lokal gateway som låter kodagenter köra mot vilken modell du än pekar dem mot – beskrev sitt eget underhållsarbetsflöde på X den 13 oktober 2026: Claude Code, drivet av Anthropics Claude Opus 5.5, med tre /loop-uppgifter som körs samtidigt, var och en bevakar en egen yta – GitHub-ärenden och pull requests, Discord-gemenskapen och feedback som kommer in på X – och åtgärdar det den hittar. Loop engineering, praktiken att hålla en agent i en loop i stället för att prompta den tur för tur, var föremål för mycket diskussion i år. Det som gör det här exemplet värt att läsa är att det kommer med ett organisationsschema.

Claude Opus 5.5 är inte nytt. Anthropic släppte det den 22 september 2026, för tre veckor sedan, till $4 per miljon indatatoken och $20 per miljon utdatatoken. Det här är inte en lanseringshistoria. Det är en historia om vad modellens standardinställningar innebär för alla som försöker kopiera en underhållsloop med tre agenter — och om vilka delar av den loopen som går sönder på sätt som handledningarna inte nämner.

Vad finns det egentligen i arbetsflödet?

Signalen är kort, så det är värt att vara precis om vad som påstås och vad som inte påstås. yetone kör tre samtidiga /loop-uppgifter i Claude Code på Opus 5.5. En övervakar förvaret – issues och pull requests. En övervakar Discord. En övervakar X. Agenten åtgärdar det den bedömer är värt att åtgärda, i loopen, utan att en människa skickar ut varje tur. Mönstret han automatiserade är det som de flesta underhållare gör dåligt: triagering. Inte kodandet. Läsandet, sorterandet, avdubblerandet och svarandet som slukar en timme om dagen.

Frasen loop engineering är bärande här. En loop är inte en agent som utför en uppgift; det är en session som ständigt återvänder till en uppgift enligt ett schema som den själv väljer, med tillståndet från den senaste iterationen fortfarande framför sig. Det är i den distinktionen som de flesta hemmagjorda versioner faller isär, och det är precis där verktygsutvecklingen har rört sig de senaste sex veckorna.

Vad Claude Codes /loop faktiskt gör i oktober 2026

Om du inte har läst den aktuella dokumentationen är versionen du minns förmodligen fel, eftersom /loop ändrade form medan loop-engineering trendade.

Ett bart /loop vill inte längre att du anger ett intervall. Utelämna det, så väljer Claude ett dynamiskt intervall – mellan en minut och en timme – baserat på vad den observerade i föregående iteration. Den väntar en kort stund medan en byggkörning slutförs eller en pull request är aktiv, och väntar mycket längre när inget är på gång. Den valda fördröjningen och anledningen till den skrivs ut i slutet av varje iteration, så att du kan se loopens eget resonemang om sin kadens. Ange ett intervall i stället – /loop 5m check the deploy – och du får ett fast cron-schema.

Om du också utelämnar prompten får du en inbyggd underhållsprompt som går igenom tre saker i ordning, varje iteration:

• Fortsätt med eventuellt oavslutat arbete från konversationen.

• Ta hand om den aktuella grenens pull request — granskningskommentarer, misslyckade CI-körningar, merge-konflikter.

• Kör städningsomgångar såsom buggjakter eller förenkling när inget annat väntar.

Du kan ersätta den standarden med dina egna instruktioner genom att skriva en loop.md — i .claude/loop.md för ett projekt, eller ~/.claude/loop.md för varje projekt som inte definierar sin egen. Ändringar träder i kraft vid nästa iteration, så du kan förfina en körande loops instruktioner utan att starta om den. Filen trunkeras efter 25 000 byte, vilket är mer än tillräckligt med utrymme för triageringsregler.

Den mekanismen är den bärande delen i en uppsättning med tre loopar, och det är den del som arbetsflödesdiagrammen oftast utelämnar. En generisk inbyggd underhållsprompt är inte en triageringspolicy. Om du vill ha en loop som läser GitHub-issues på samma sätt som ditt projekt läser GitHub-issues – vad som räknas som en dubblett, vad som får en etikett i stället för ett svar, vad som aldrig får ett svar – måste policyn finnas i loop.md, inte i prompten du skrev när du startade sessionen.

Gränserna som avgör om tre är ett tal eller en slogan

Tre samtidiga loopar är där begränsningarna börjar göra sig gällande, och de är värda att lista innan du kopierar någon annans uppsättning.

• Samtidighetstak – en session har plats för upp till 50 schemalagda uppgifter samtidigt, så tre loopar är långt ifrån gränsen. Den bindande begränsningen är inte antalet uppgifter, det är uppmärksamhet: tre loopar innebär tre strömmar av verktygsanrop som konkurrerar om samma session.

• Utgång — återkommande uppgifter raderar sig själva sju dagar efter skapandet och kör en gång till på vägen ut. En underhållsloop som tystnade på dag åtta är det enskilt vanligaste felmodet, och den misslyckas tyst.

• Återställningsasymmetrier — återuppta en session med --resume eller --continue och cron-schemalagda uppgifter kommer tillbaka, utom de återkommande som har löpt ut. En självstyrd loop återställs inte alls; du måste starta den igen.

• Beteende vid upptagen session — en uppgift utlöses mellan turer, aldrig mitt i ett svar. Om en lång agentisk tur körs när en loop förfaller, väntar utlösningen. Missade intervall staplas inte på varandra; de slås samman till en enda utlösning.

• Jitter – återkommande uppgifter körs avsiktligt sent, med upp till halva intervallet till nästa körning och högst 30 minuter, så att en flotta av sessioner inte sammanfaller på samma sekund. En uppgift var tionde minut startar allt från i tid till fem minuter sent. Femminutersfallet är undantaget: Claude Code flyttar det 15 sekunder tidigare för att hålla varje körning inom prompt-cache-fönstret.

• Maskinen måste vara på — loopar utlöses endast medan Claude Code körs och är inaktiv. Att stänga locket stoppar dem. Det finns ingen ikappkörning för de timmar du var borta.

Det sistnämnda är anledningen till att det här arbetsflödet är en underhållares uppsättning snarare än ett plattformsteams. Tre loopar på en maskin, i en och samma session, är ett sätt att hålla ett hektiskt projekt med öppen källkod igång medan du gör något annat; det är inte en tjänst.

Varför detta arbetsflöde är specifikt för Claude Opus 5.5, och inte bara ”en agent”

Kör en loop med tre agenter mot en modell utan ett stort kontextfönster och looparna tillbringar dagen med att läsa om. Varje iteration läser in issue-tråden, PR-diffen och Discord-historiken igen; om fönstret är litet sammanfattas historiken bort och loopens bedömning försämras tyst i takt med att sessionen åldras. Claude Opus 5.5 har ett kontextfönster på 1M tokens med 128K tokens utdata, vilket är det som gör att en triage-loop kan hålla en riktig issue-backlog plus en konversation plus de senaste iterationerna samtidigt. Den är också prissatt till $4 / $20 per miljon tokens, och dess cacheläsningar ligger på $0,20 per miljon — en femtedel av inputpriset — vilket spelar större roll än vanligt här, eftersom en loop är den mest cachevänliga arbetsbelastning som finns. Samma systemprompt, samma verktygsdefinitioner, samma repo-kontext, om och om igen.

Den andra anpassningen är standardinställningen för tänkande, och den slår åt andra hållet beroende på vad varje loop gör. Claude Opus 5.5 kör adaptivt tänkande alltid på, med ansträngning som standard medel – en nivå under Claude Opus 5:s standard. Ansträngning förändrar inte bara kvaliteten; den förändrar volymen av verktygsanrop. En loop som triagerar ärenden och en som redigerar kod vill ha olika inställningar, och inställningen med lägst ansträngning är också ett eget schemaläggningsproblem: i en självstyrd loop väljer modellen sin egen fördröjning till nästa uppvaknande, så en triageloop med låg ansträngning och en åtgärdande loop med hög ansträngning kommer att hålla olika takt mot samma kodförråd. Det finns ingen inställning som får dem att stämma överens. Poängen är att veta vilken som är vilken, eftersom taktskillnaden är det du kommer att se först.

Om du vill köra loopen och fixaren mot olika leverantörers modeller – triage på något billigt, fixar på Claude Opus 5.5 – är det ett routingbeslut snarare än ett Claude Code-beslut, och det är anledningen till att en gateway sitter framför sessionen.

Testar detta utan att satsa produktionen på det

Den rimliga invändningen mot ett upplägg med tre loopar är att det sätter en autonom agent framför dina användares ärenden redan första eftermiddagen. Loopen kommer att kommentera. Den kommer att stänga saker. Det ärliga sättet att införa detta är att köra en loop i torrkörningsläge i en vecka mot en skrivskyddad GitHub-token och se om dess triagebedömningar matchar dem du gjorde för hand — och, separat, att dirigera modellen själv till en plats där du kan mäta den innan du binder dig.

På OrcaRouter, anthropic/claude-opus-5.5tillhandahålls till A​nthropics listpris utan påslag, från en enda slutpunkt som talar både de OpenAI-kompatibla och A​nthropic Messages-formaten — så en Claude Code-session och ett skript som talar med samma modell behöver inte två integrationer. A​nthropic publicerade sin egen prissättning på $4 / $20 den 22 september 2026; om det listpriset ändras följer en vidarebefordrande gateway med det samma dag i stället för vid nästa faktureringscykel, vilket är den variant av detta du vill ha när du dimensionerar en loop som kan köra i månader. Automatisk failover mellan leverantörer täcker fallet som dokumentationen varnar för och ingen testar: loopen stoppar inte för att en uppström returnerade en 429 klockan tre på morgonen. Modellfusion och routing-DSL spelar mindre roll här — en triage-loop vill ha en enda modell, konsekvent, eftersom konsekvens är det som gör dess bedömningar granskningsbara.

Vad ska man göra med siffran tre?

Loop engineerings reputationsproblem är att det mesta som demonstrerades i år var en enda loop som körde ett enda snävt jobb i en demo. yetones uppsättning är intressant eftersom den består av tre loopar över tre olika indata – repot, chattgemenskapen, den publika tidslinjen – vilket är formen på det faktiska jobb en maintainer inte har tid med. Det är också formen som blottlägger varje begränsning ovan: utgång, jitter, återställning, taktning, och det faktum att looparna bara körs medan maskinen är på.

Det som går att överföra är inte antalet. Det är att varje loop fick sin egen yta, sin egen policy i loop.md, och sin egen anledning att vakna — och att personen som körde det kunde se, från iterationsloggen, varför varje loop valde den fördröjning den valde. Det är en uppsättning du faktiskt kan granska en vecka senare. Vilket, med tanke på att var och en av dessa loopar löper ut på dag åtta, är ungefär så lång tid du har på dig att avgöra om du ska bygga den igen.

Värt att säga rent ut: det här är en utövares konfiguration, beskriven av sin upphovsperson på X, inte någon leverantörsrekommenderad vägledning. Anthropics dokumentation för Claude Opus 5.5 och Claude Codes /loop berättar vad verktygen gör. Den säger inte att tre är rätt antal, och det gör ingen annan heller ännu.

När triage-loopen och fixningsloopen vill ha olika modeller: Kör loopen och fixaren genom en och samma endpoint som serverar Claude Opus 5.5 till Anthropics listpris från en enda endpoint som talar både det OpenAI-kompatibla formatet och Anthropic Messages-formatet.

Modellval som detta är också där fellägena visar sig: de dokumenterade AI-incidenterna och agentfelen bakom modeller i den här klassen samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och omstridd flagga.