Loop-engineering bij Three Agents: Wat de Magpie Workflow van yetone zegt over het onbeheerd draaien van Claude Opus 5.5

Het interessantste aan de setup van yetone is niet het model. Het is het getal drie. De beheerder van Magpie — een lokale gateway waarmee coding agents kunnen draaien tegen welk model je ze ook richt — beschreef zijn eigen onderhoudsworkflow op X op 2026-10-13: Claude Code, aangedreven door Anthropic's Claude Opus 5.5, met drie /loop-taken die tegelijk draaien, elk met het oog op een ander oppervlak — GitHub-issues en pull requests, de Discord-community en feedback die binnenkomt op X — en die repareren wat ze vinden. Loop engineering, de praktijk waarbij je een agent blijft laten cykelen in plaats van hem beurt voor beurt te prompten, was dit jaar een veelbesproken onderwerp. Wat dit voorbeeld de moeite waard maakt om te lezen, is dat er een organigram bij zit.

Claude Opus 5.5 is niet nieuw. Anthropic heeft het op 2026-09-22 uitgebracht, drie weken geleden, voor $4 per miljoen inputtokens en $20 per miljoen outputtokens. Dit is geen lanceringsverhaal. Het is een verhaal over wat de standaardinstellingen van het model impliceren voor iedereen die een onderhoudslus met drie agents probeert na te bouwen — en over welke delen van die lus stuklopen op manieren die de tutorials niet vermelden.

Wat staat er eigenlijk in de workflow?

Het signaal is kort, dus het loont om precies te zijn over wat wel en niet wordt beweerd. yetone draait drie gelijktijdige /loop-taken in Claude Code op Opus 5.5. Eén houdt de repository in de gaten — issues en pull requests. Eén houdt Discord in de gaten. Eén houdt X in de gaten. De agent repareert wat hij het repareren waard vindt, in de loop, zonder dat een mens elke beurt opdrachten uitstuurt. Het patroon dat hij heeft geautomatiseerd, is het patroon dat de meeste maintainers slecht doen: triage. Niet het coderen. Het lezen, sorteren, dedupliceren en beantwoorden dat een uur per dag opslokt.

De term loop engineering is hier cruciaal. Een loop is geen agent die een taak uitvoert; het is een sessie die volgens een door haarzelf gekozen schema steeds op een taak terugkomt, met de toestand van de laatste iteratie nog voor zich. Dat onderscheid is waar de meeste zelfgemaakte versies stuklopen, en het is precies waar de tooling zich de afgelopen zes weken naartoe heeft bewogen.

Wat Claude Code's /loop in oktober 2026 echt doet

Als je de huidige documentatie niet hebt gelezen, is de versie die je je herinnert waarschijnlijk onjuist, omdat /loop van vorm veranderde terwijl loop engineering trending was.

Een kale /loop vraagt je niet langer een interval op te geven. Laat je het weg, dan kiest Claude er dynamisch een — tussen één minuut en één uur — op basis van wat hij in de vorige iteratie heeft waargenomen. Het wacht kort terwijl een build wordt afgerond of een pull request actief is, en wacht veel langer wanneer er niets in behandeling is. De gekozen vertraging en de reden ervoor worden aan het einde van elke iteratie afgedrukt, zodat je de eigen redenering van de loop over zijn cadans kunt zien. Geef in plaats daarvan een interval op — /loop 5m check the deploy — en je krijgt een vast cron-schema.

Laat ook de prompt weg, en je krijgt een ingebouwde onderhoudsprompt die bij elke iteratie drie dingen in volgorde doorloopt:

• Ga verder met eventueel onvoltooid werk uit het gesprek.

• Besteed aandacht aan de pull request van de huidige branch — reviewopmerkingen, mislukte CI-runs, mergeconflicten.

• Voer opschoonrondes uit, zoals bugjachten of vereenvoudigingen, wanneer er niets anders openstaat.

Je kunt die standaard vervangen door je eigen instructies door een loop.md te schrijven — in .claude/loop.md voor een project, of ~/.claude/loop.md voor elk project dat geen eigen bestand definieert. Wijzigingen worden van kracht bij de volgende iteratie, dus je kunt de instructies van een actieve loop verfijnen zonder deze opnieuw te starten. Het bestand wordt afgekapt na 25.000 bytes, wat meer dan genoeg ruimte biedt voor triageringsregels.

Dat mechanisme is het dragende deel van een drie-lussenopzet, en het is het deel dat de workflowdiagrammen meestal weglaten. Een generieke ingebouwde onderhoudsprompt is geen triagebeleid. Als je een lus wilt die GitHub-issues leest zoals je project GitHub-issues leest — wat als duplicaat telt, wat een label krijgt in plaats van een antwoord, wat nooit een antwoord krijgt — dan moet het beleid in loop.md, niet in de prompt die je typte toen je de sessie startte.

De grenzen die bepalen of drie een getal of een slogan is

Drie gelijktijdige loops zijn waar de beperkingen echt beginnen te knellen, en het loont om ze op te sommen voordat je iemands setup kopieert.

• Plafond voor gelijktijdigheid — een sessie kan maximaal 50 geplande taken tegelijk bevatten, dus drie loops komen lang niet in de buurt van de limiet. De beperkende factor is niet het aantal taken, maar aandacht: drie loops betekenen drie stromen toolaanroepen die om dezelfde sessie strijden.

• Afloop — terugkerende taken verwijderen zichzelf zeven dagen na aanmaak en worden bij het verdwijnen nog één keer uitgevoerd. Een onderhoudslus die op dag acht geruisloos stopte, is de meest voorkomende faalmodus, en hij faalt geruisloos.

• Asymmetrieën bij herstel — hervat een sessie met --resume of --continue en cron-geplande taken komen terug, behalve de terugkerende die verlopen zijn. Een self-paced loop wordt helemaal niet hersteld; die moet je opnieuw starten.

• Gedrag bij drukke sessies — een taak wordt tussen beurten geactiveerd, nooit midden in een reactie. Als een lange agentische beurt draait wanneer een lus aan de beurt is, wacht de activering. Gemiste intervallen stapelen zich niet op; ze vallen samen tot één activering.

• Jitter — terugkerende taken worden bewust later uitgevoerd, tot de helft van de tussenpoos tot de volgende uitvoering en maximaal 30 minuten, zodat een vloot van sessies niet op dezelfde seconde samenkomt. Een taak die elke tien minuten wordt uitgevoerd, start ergens tussen op tijd en vijf minuten te laat. Het geval van vijf minuten is de uitzondering: Claude Code verschuift die 15 seconden naar voren om elke uitvoering binnen het prompt-cachevenster te houden.

• Vereiste dat de machine aan staat — loops worden alleen uitgevoerd terwijl Claude Code draait en inactief is. De laptop dichtklappen stopt ze. Er is geen inhaalslag voor de uren dat je weg was.

Dat laatste is de reden dat deze workflow een opzet van een maintainer is en niet die van een platformteam. Drie loops op één machine, in één sessie, is een manier om een druk open-sourceproject draaiende te houden terwijl je iets anders doet; het is geen service.

Waarom deze workflow specifiek is voor Claude Opus 5.5, en niet zomaar "een agent"

Laat een drie-agentlus draaien tegen een model zonder groot contextvenster, en de lussen zijn de hele dag aan het herlezen. Elke iteratie neemt de issue-thread, de PR-diff en de Discord-geschiedenis opnieuw tot zich; als het venster klein is, wordt die geschiedenis tot een samenvatting gereduceerd en verslechtert het beoordelingsvermogen van de lus geruisloos naarmate de sessie ouder wordt. Claude Opus 5.5 heeft een contextvenster van 1M tokens met 128K tokens output, waardoor een triage-lus tegelijk een echte issuebacklog, een conversatie en de laatste paar iteraties kan vasthouden. De prijs is ook $4 / $20 per miljoen tokens, en de cache-reads kosten $0.20 per miljoen — een vijfde van de invoerprijs — wat hier meer dan gewoonlijk van belang is, omdat een lus bij uitstek de meest cachevriendelijke werklast is die er bestaat. Dezelfde systeemprompt, dezelfde tooldefinities, dezelfde repocontext, keer op keer.

De tweede fit is de standaard voor thinking, en die pakt anders uit afhankelijk van wat elke lus doet. Claude Opus 5.5 draait adaptive thinking altijd aan, waarbij effort standaard op medium — één niveau onder de standaard van Claude Opus 5. Effort verandert niet alleen de kwaliteit; het verandert ook het volume aan tool-aanroepen. Een lus die issues triageert en een die code bewerkt willen verschillende instellingen, en de instelling met de laagste effort is ook een eigen planningsprobleem: bij een lus die zijn eigen tempo bepaalt, kiest het model zijn eigen volgende wekvertraging, dus een triagelus met lage effort en een oplossingslus met hoge effort zullen een ander tempo aanhouden bij dezelfde repository. Er is geen instelling die ze het eens laat zijn. Het punt is te weten welke welke is, want het tempoverschil is wat je als eerste zult zien.

Als je de loop en de fixer tegen de modellen van verschillende leveranciers wilt draaien — triage op iets goedkoops, fixes op Claude Opus 5.5 — dan is dat een routeringsbeslissing en niet iets van Claude Code, en dat is de reden waarom er een gateway vóór de sessie staat.

Dit proberen zonder de productie op het spel te zetten

Het redelijke bezwaar tegen een opstelling met drie loops is dat die op de eerste middag al een autonome agent voor de issues van je gebruikers zet. De loop gaat commentaar geven. Hij gaat dingen sluiten. De eerlijke manier om dit in te voeren is om één loop een week in dry-runmodus te laten draaien met een alleen-lezen GitHub-token en te kijken of de triagebeoordelingen ervan overeenkomen met de beoordelingen die je handmatig hebt gemaakt — en, afzonderlijk, om het model zelf ergens onder te brengen waar je het kunt meten voordat je je vastlegt.

Op OrcaRouter anthropic/claude-opus-5.5wordt aangeboden tegen Anthropics lijstprijs, zonder dat er een opslag bovenop komt, via één endpoint dat zowel de OpenAI-compatibele als de Anthropic Messages-vormen spreekt — zodat een Claude Code-sessie en een script dat met hetzelfde model praat niet twee integraties nodig hebben. Anthropic publiceerde zijn eigen prijzen van $4 / $20 op 2026-09-22; als die lijstprijs verandert, beweegt een pass-through-gateway dezelfde dag mee in plaats van pas in de volgende factureringscyclus, en dat is de versie die je wilt wanneer je een loop aan het dimensioneren bent die maanden kan draaien. Automatische failover tussen providers dekt het geval waarover de documentatie waarschuwt en dat niemand test: de loop stopt niet omdat één upstream om drie uur 's nachts een 429 teruggaf. Model fusion en de routing-DSL doen hier minder ter zake — een triage-loop wil één model, consequent, want consistentie is wat de beoordelingen controleerbaar maakt.

Wat te doen met het getal drie

Het reputatieprobleem van loop-engineering is dat het meeste dat dit jaar werd gedemonstreerd één loop was die één nauwe taak uitvoerde in een demo. De setup van yetone is interessant omdat het drie loops over drie verschillende inputs zijn — de repository, de chatcommunity, de publieke tijdlijn — wat de vorm is van het daadwerkelijke werk waarvoor een maintainer geen tijd heeft. Het is ook de vorm die elke hierboven genoemde beperking blootlegt: vervaltijd, jitter, herstel, tempo, en het feit dat de loops alleen draaien terwijl de machine aan staat.

Het overdraagbare deel is niet het aantal. Het is dat elke loop zijn eigen oppervlak kreeg, zijn eigen beleid in loop.md, en zijn eigen reden om wakker te worden — en dat de persoon die het draait, uit het iteratielog kon opmaken waarom elke loop de vertraging koos die hij koos. Dat is een opzet die je een week later daadwerkelijk kunt auditen. Wat, aangezien elk van deze loops op dag acht verloopt, ongeveer de tijd is die je hebt om te beslissen of je het opnieuw moet bouwen.

Het is goed om ronduit te zeggen: dit is de opzet van één professional, beschreven door de auteur op X, geen door de leverancier aanbevolen richtlijn. De documentatie van Anthropic voor Claude Opus 5.5 en Claude Code's /loop vertelt je wat de tools doen. Er staat niet in dat drie het juiste aantal is, en dat doet voorlopig niemand anders ook niet.

Wanneer de triage-lus en de fix-lus verschillende modellen willen: Laat de lus en de fixer via één endpoint lopen dat Claude Opus 5.5 tegen de lijstprijs van A​nthropic serveert, vanaf één endpoint dat zowel de OpenAI-compatibele als de A​nthropic Messages-vormen spreekt.

Ook bij modelkeuzes zoals deze komen de faalmodi naar voren: de gedocumenteerde AI-incidenten en agentfouten achter modellen in deze klasse zijn verzameld in het OrcaRouter AI Incident Archive, waar elke vermelding zijn eigen bronnen, ernstgraad, betrouwbaarheidsgraad en betwistingsmarkering bevat.