Claude Code Workflows: 41 agents, 5M tokens, getest
Eenenveertig agents. Zoveel Haiku-instanties startte een van mijn Claude Code-workflows vorige week tegelijk op, allemaal tegelijkertijd, om elke skill die ik had geïnstalleerd te auditen en te scoren. Ik keek hoe de teller opliep in de terminal — 12, 28, 41 — elk een volledige, onafhankelijke Claude-aanroep die een ander recept beoordeelde aan de hand van criteria die ik aan de orchestrator had meegegeven. Het hele proces verwerkte ruwweg 5 miljoen input tokens voordat het klaar was.
Dat getal deed me stoppen. Vijf miljoen. Bij de meeste prijsberekeningen klinkt dat als een paniek-inducerende rekening. Maar hier is de wending die het hele feature voor me herkadreerde: de output was klein. Een gerangschikte rapportage, een paar honderd regels. Al die tokenuitgave ging naar lezen — crawlen, parsen, scoren — niet naar genereren. Rekenintensief, zeker. Buitensporig duur? Niet echt. Haiku input tokens zijn goedkoop, en 41 ervan die parallel lezen waren in een fractie van de kloktijd klaar die een enkele agent nodig zou hebben gehad om sequentieel door dezelfde stapel te ploegen.
Dat is het moment waarop Claude Code-workflows voor mij klikten. Niet als een buzzword van de Opus 4.8-lancering. Als een specifiek gereedschap met een specifieke vorm — een dat oprecht anders is dan skills, subagents en agentteams, en een dat verschrikkelijk makkelijk verkeerd te gebruiken is als je die vorm niet begrijpt.
Dus dat is wat dit bericht is. Geen functieaankondiging. Een praktijkgids. Aan het eind weet je precies welke van de vijf orkestratieprimitieven je moet pakken — skill, subagent, agentteam, workflow of de /goal-lus — en ruwweg wat elk je kost aan tokens en complexiteit. Ik leerde het meeste hiervan op de iets dure manier. Dat hoeft voor jou niet.
Wat Anthropic daadwerkelijk heeft geleverd met Workflows op 28 mei
Dynamische workflows landden op 28 mei 2026, gebundeld in de Claude Opus 4.8-release als research preview. Als je al mijn analyse van de inspanningsniveaus van Opus 4.8 hebt gelezen, zie workflows als de andere helft van die release — het model kreeg een denkknop, en Claude Code kreeg een manier om dat denken over honderden agents tegelijk te verspreiden.
Je hebt Claude Code v2.1.154 of later nodig om ze te draaien. Ze werken in de CLI, de desktop-app en de VS Code-extensie. En de manier waarop je er een triggert is bijna verdacht terloops: je stopt gewoon het woord workflow ergens in je prompt. Zeg "draai een workflow om elke API-route te auditen op ontbrekende auth-checks" en Claude doet iets wat het nog nooit eerder heeft gedaan — het schrijft een JavaScript-orkestratiescript ter plekke, geeft het aan een achtergrondruntime, en die runtime start de agents op.
Twee harde limieten die het waard zijn om in je geheugen te branden: de runtime draait maximaal 16 agents tegelijkertijd, en het limiteert een enkele workflow op 1.000 agents totaal. Mijn 41-agent skill-audit kwam niet in de buurt van het plafond. Maar het is heel makkelijk om een prompt te schrijven die dat wel doet — "analyseer elk bestand in deze monorepo" tegen een paar duizend bestanden zal die limiet snel bereiken en de wachtrij blijven vullen. We komen hierop terug, want het is de allergrootste manier waarop mensen geld verbranden met deze feature.
Hier is het architecturale detail dat er echt toe doet. Het detail dat workflows anders maakt en niet gewoon "subagents maar meer." Laat me het je laten zien.
Het ene ding dat workflows anders maakt: het plan leeft buiten Claudes hoofd
Elk ander orkestratietool in Claude Code houdt zijn plan binnen het contextvenster van het model. De hoofdsessie onthoudt wat het delegeerde, volgt wat er terugkwam, houdt de lopende status bij in zijn eigen werkgeheugen. Dat is prima voor een handvol taken. Het valt uit elkaar op schaal, omdat contextvensters eindig zijn en elk gedelegeerd resultaat dat je terugstopt ruimte opeet die je nodig hebt voor daadwerkelijk redeneren.
Workflows breken die regel volledig. Het plan en de uitvoeringsstatus leven in een extern JavaScript-bestand, niet in Claudes context.
Lees dat nog eens, want het is het hele spel. Wanneer je een workflow start, besluit Claude niet alleen om agents te spawnen — het schrijft een echt script: lussen, vertakkingslogica, hoeveel agents te lanceren, wat elk krijgt, hoe de resultaten te combineren, welke verificatieronden te draaien. Dat script wordt opgeslagen in een map die je opgeeft. Een aparte runtime voert het uit in een geïsoleerde omgeving, volledig los van je chatsessie. De tussenresultaten — elke ruwe output van elke agent, elke kladberekening — blijven in de variabelen van het script. Ze raken je gesprek nooit aan.
Wat terugkomt naar je sessie is alleen het uiteindelijke, gecombineerde antwoord.
Stel je het verschil fysiek voor. Met subagents is je hoofdsessie een manager die een klembord vasthoudt en persoonlijk elk rapport bijhoudt als het binnenkomt. Met een workflow schrijft je hoofdsessie een programma, geeft het aan een buildserver, loopt weg, en komt terug bij een enkel afgewerkt artefact. Het klembord raakt nooit vol. Daarom blies mijn 41-agent audit het contextvenster niet op, ook al verwerkte het 5 miljoen tokens aan input — 99% van die tokens leefden en stierven binnen de variabelen van het script. Mijn sessie zag alleen het gerangschikte rapport aan het eind.
Dit heeft twee gevolgen die ik niet waardeerde tot ik er een paar had gedraaid. Ten eerste, omdat de orkestratie een opgeslagen bestand is, zijn workflows heruitvoerbaar en versiebeheerbaar. Je kunt het script committen, diffen, aan een teamgenoot geven. Sla een nuttige op en het wordt een slash-commando — je branch-review-workflow wordt /my-review, voor altijd herhaalbaar. Ten tweede, en dit is cruciaal voor het mentale model: de gespawnde agents praten niet met elkaar. Elk is een volledig onafhankelijke Claude-aanroep met zijn eigen geïsoleerde context. Ze waaieren uit, doen hun ene taak, retourneren een samenvatting, en dat is het. Geen onderling gepraat. Geen debat. Het combineren gebeurt in de logica van het script, niet in een gesprek tussen agents.
Hou dat "agents praten niet"-detail vast. Het is de exacte lijn die een workflow scheidt van een agentteam — en die lijn verkeerd trekken is hoe mensen de verkeerde tool kiezen en ervoor betalen.
Skill vs subagent vs agentteam vs workflow vs /goal: het mentale model
Juist. Hier is het deel waarvoor je kwam. Vijf primitieven, en de eerlijke waarheid is dat de meeste mensen er maar twee nodig hadden en uit enthousiasme naar de dure grepen. Ik ook. Laat me elk doorlopen zoals ik ze nu daadwerkelijk gebruik, van goedkoopst naar duurst, want kosten en complexiteit klimmen samen in een schone ladder: skills → subagents → agentteams → workflows. De /goal-lus staat er als een andere as helemaal naast, en ik zal uitleggen waarom.
Wat is een skill in Claude Code?
Een skill is een herbruikbaar recept dat draait binnen je persoonlijke Claude Code-sessie. Het is een single-agent automatisering — een opgeslagen set instructies die Claude op aanvraag kan oproepen, door jou of door andere tools, zonder iets parallels op te starten.
Dat is de onderste trede, en het zou je standaard moeten zijn. Een skill waaiert niet uit. Het krijgt geen eigen aparte context. Het draait daar in je sessie, als een functie die je bij naam kunt aanroepen. Mijn SEO-check routine, mijn commit-berichtformatter, mijn "audit dit bestand op N+1-queries"-recept — allemaal skills. Goedkoop om te draaien, triviaal om te onderhouden en herbruikbaar voor alles. Ik schreef een volledig argument voor het bouwen van skills voordat je ooit naar agents grijpt, en ik sta er nu sterker achter dan toen ik het publiceerde. De overgrote meerderheid van "ik heb hier een agent voor nodig"-instincten zijn eigenlijk "ik heb hier een skill voor nodig."
Gebruik een skill wanneer de taak klein, herhaalbaar en op zichzelf staand is. Als je het als een recept kunt beschrijven, is het een skill. Klaar.
Wat is een subagent?
Een subagent draait parallel aan je hoofdsessie maar deelt niet het contextvenster, kan niet met andere subagents praten, en rapporteert zijn resultaat alleen terug aan de hoofdsessie.
Dit is de volgende trede, en het sleutelwoord is aflasten. Een subagent is voor wanneer je een zijtaak afgehandeld wilt hebben zonder dat het je hoofdthread's geheugen vervuilt. Zeg dat ik diep in een refactor zit en de test-suite-uitleg samengevat wil hebben zonder mijn context te ontsporen — ik geef het aan een subagent. Die gaat erheen, doet het ding, komt terug met een antwoord, en het werkgeheugen van mijn hoofdsessie blijft schoon. De afweging die het elimineert is communicatie-overhead. Een subagent coördineert niet, onderhandelt niet, licht niemand anders in. Het is een eenrichtingsboodschap. Dat is een feature, geen beperking — het maakt subagents goedkoop en voorspelbaar.
Gebruik een subagent wanneer je een simpele, onafhankelijke zijtaak hebt en het uit je hoofdcontext wilt hebben. Geen samenwerking nodig. Gewoon "ga dit afhandelen en rapporteer terug."
Wat is een agentteam?
Een agentteam is een kleine groep agents die communiceren, taken delen en samenwerken richting een doel, binnen hun eigen gedeelde contextvenster — agents debatteren, coördineren en bouwen voort op elkaars werk.
Nu zitten we op de dure trede, en het onderscheidende woord is praten. In tegenstelling tot subagents kunnen de leden van een agentteam elkaar zien en informatie uitwisselen. Ze delen context. De bevinding van de ene agent informeert die van de andere. Ze debatteren, dragen over, convergeren. Ik heb precies uitgezocht hoe en wanneer agents met elkaar moeten praten in een apart bericht, en de korte versie is: dat gesprek is het hele punt, en het is ook waarom teams echt geld kosten. Gedeelde context plus heen-en-weer betekent meer tokens, meer rondes, meer compute.
Gebruik een agentteam wanneer de taak oprecht collaboratief is — wanneer de discussie tussen agents iets produceert dat geen enkele agent alleen zou kunnen, en wanneer context-deling tussen hen vitaal is. Architectuurdebatten. Multi-perspectiefbeoordelingen waar de kritiek van de ene agent het voorstel van de andere aanscherpt. Niet voor doorvoer. Voor overleg.
Wat is een workflow?
Een workflow is een door JavaScript georkestreerd systeem dat veel onafhankelijke agents opstart — mogelijk honderden — die parallel draaien op verschillende stukken van een taak, en hun resultaten combineert in scriptlogica. De agents communiceren niet; het plan leeft in een extern bestand, niet in Claudes context.
Bovenste trede. Krachtigst, complexst, duurst. Alles wat ik twee secties geleden beschreef. Het bepalende kenmerk, het ding dat het scheidt van een agentteam: breedte zonder gesprek. Een team is een paar agents die praten. Een workflow is veel agents die niet praten — elk maalend op zijn eigen segment, resultaten samengevoegd door code. Mijn 41 Haiku-scorers waren een schoolvoorbeeld van een workflow: 41 onafhankelijke taken, nul onderling gepraat, één gecombineerde rangschikking aan het eind.
Gebruik een workflow wanneer een taak van nature uiteenvalt in veel onafhankelijke, parallelliseerbare stukken. Een hele codebase crawlen. Een grote dataset scoren. Breed onderzoek over tientallen invalshoeken. Het soort werk waarbij de stukken niet over elkaar hoeven te weten — ze moeten gewoon allemaal gedaan worden, snel, en opgerold.
Wat doet het /goal-commando?
/goal draait een lusproces waarbij een agent blijft itereren op hetzelfde probleem totdat aan een voltooiingsvoorwaarde is voldaan — het kan veel cycli draaien en lang duren.
Hier is waarom ik zei dat /goal op een andere as zit. Alles hierboven gaat over hoeveel agents en of ze praten. /goal gaat over hoe vaak één poging itereert. Het is een lus. Je geeft het een doel en een definitie van klaar, en het maalt — probeer, evalueer, verfijn, probeer opnieuw — totdat aan de voorwaarde is voldaan. Het kan een dozijn cycli draaien. Het kan lang duren. Dat is verwacht.
Gebruik /goal wanneer de taak diepte nodig heeft — iteratieve verfijning richting een hard doel — in plaats van breedte.
En dat woord, diepte, is de sleutel tot de hele kaart. Laat me het concreet maken.
Breedte vs diepte: het kader dat dit eindelijk deed klikken
Hier is de ene zin die reorganiseerde hoe ik over dit alles denk:
Workflows zijn breedte. /goal is diepte.
Een workflow spreidt zich uit — veel agents, elk een ander segment behandelend, allemaal tegelijk. Breedte. Je gebruikt het wanneer het werk breed is: honderd bestanden om te scannen, vijftig claims om te verifiëren, een grote platte stapel onafhankelijke taken. De winst is parallellisme. Je ruilt tokens in voor kloktijd en krijgt een breed karwei snel gedaan.
De /goal-lus boort zich omlaag — één poging, steeds verfijnd, tot het goed is. Diepte. Je gebruikt het wanneer het werk diep is: een enkel lastig probleem dat cyclus na cyclus doorgehamerd moet worden tot het een lat haalt. De winst is doorzettingsvermogen. Je ruilt tijd in voor kwaliteit op één moeilijk ding.
Zodra ik dat kader had, stopte het kiezen van het gereedschap met gokwerk zijn. Breed en ondiep? Workflow. Smal en diep? /goal. Beide nodig — een breed karwei waar elk stuk ook iteratieve verfijning nodig heeft? Dat is waar je ze voorzichtig combineert, en ik zal eerlijk zijn over hoe dat gaat zo meteen, want het is krachtig en het is een geweldige manier om een fortuin te verbranden.
Deze breedte-versus-diepte lens verklaart ook de twee headlinefeatures die Anthropic bovenop workflows heeft geleverd. Beide zijn workflows onder de motorkap, gericht op de twee uiteinden van dat spectrum.
Ultra Code en /deep-research: workflows met de handschoenen uit
Twee dingen zitten bovenop de ruwe workflow-engine, en je zou moeten weten dat ze bestaan voordat je beslist of je ze nodig hebt.
Ultra Code (/effort ultracode) is de maximale instelling: hoogste redeneerinspanning plus automatische workflow-orkestratie. Zet het aan en Claude beslist, voor elke substantiële taak in de sessie, of er een workflow voor gepland moet worden. Een enkel verzoek kan uitmonden in meerdere workflows achter elkaar — een om de code te begrijpen, een om de wijziging door te voeren, een om het te verifiëren. Het is de meest capabele modus die Claude Code heeft. Het is ook, niet verrassend, het duurste dat je kunt draaien. Hoogste inspanning verbrandt de meeste denktokens, en dat verpakken in automatische orkestratie vermenigvuldigt het aantal agents. Ik grijp naar ultracode wanneer ik iets doe dat oprecht moeilijk en oprecht de moeite waard is. Ik laat het niet standaard aanstaan. Zo krijg je een verrassende rekening.
/deep-research is de ingebouwde workflow gericht op de onderzoeksvorm. Stel een vraag en het waaiert webzoekopdrachten uit over meerdere invalshoeken, haalt bronnen op en controleert ze kruislings, laat agents stemmen over concurrerende claims, en synthetiseert een enkel geciteerd rapport. Het is een workflow speciaal gebouwd voor breedte van onderzoek — breedte toegepast op kennis in plaats van code. Als je de diverse deep-research-tools hebt gebruikt die rondzweven, dan is dit dat patroon, native in Claude Code, rijdend op dezelfde orkestratieengine als mijn 41-agent audit.
Je beheert het allemaal met één commando: /workflows. Draai het op elk moment om te zien wat er draait, wat er klaar is, en om een voortgangsweergave te openen — of om een workflow te stoppen die duidelijk ontspoort. Ik heb die stopknop ingedrukt. Meer dan eens. Wat me brengt bij het deel van dit bericht dat ik het meest wil dat je leest.
Wat ik fout deed: de tokenfouten waarvoor niemand je waarschuwt
Ik zal eerlijk tegen je zijn — mijn eerste instinct met workflows was ze op alles te gooien, en dat was een fout die me tokens kostte en me de echte regels leerde.
Fout één: ik gebruikte een workflow voor een karwei dat niet breed was. In het begin startte ik een workflow voor een taak die eigenlijk gewoon drie sequentiële stappen op één bestand was. Het optuigen van de orkestratie, het schrijven van het script, het lanceren van agents — al die overhead, voor iets dat een enkele skill in een kwart van de tokens had afgehandeld. Workflows zijn overkill voor kleine of simpele taken, punt uit. De orkestratie kost iets zelfs voordat de agents draaien. Als de taak niet oprecht uiteenvalt in veel onafhankelijke stukken, betaal je de opzetbelasting voor niets.
Fout twee: ik was vaag, en een workflow nam me letterlijk. Ik vroeg er een om "de codebase te reviewen op problemen." Geen scope, geen deliverable, geen grenzen. Het waaierte vrolijk uit over veel meer bestanden dan me iets kon schelen, elke agent een volledige Claude-aanroep, de input-tokenmeter draaiend als een gokkast. Dit is de faalfactor. Workflows kunnen input tokens absurd snel verbranden bij brede taken, precies omdat ze ontworpen zijn om breed te crawlen. Een workflow doet precies wat je zei — en op de schaal van honderden parallelle agents omvat "precies wat je zei" elke losse interpretatie van een slordige prompt.
De oplossing voor beide is dezelfde, en het is saai, en het werkt: wees expliciet en specifiek. Definieer het deliverable. Begrens de scope. "Audit de 14 bestanden in app/Http/Controllers op ontbrekende autorisatiemiddleware en retourneer een tabel van bestand, route en de ontbrekende check" geeft de orchestrator een muur om bij te stoppen. "Review de code" geeft het een continent.
Hier is de regel waar ik nu daadwerkelijk naar leef. Een workflow is het juiste gereedschap alleen wanneer al het volgende waar is: de taak is groot, de stukken zijn onafhankelijk, en die stukken zijn parallelliseerbaar. Mis er een van en je hebt de verkeerde primitief gekozen. Groot maar sequentieel? Gebruik /goal. Klein maar herhaald? Gebruik een skill. Collaboratief en discussie-gedreven? Gebruik in plaats daarvan een agentteam. De orkestratiekeuzes volgen dezelfde taakgevormde logica die ik doorwerkte in mijn analyse van agent-zwermarchitectuur — match de structuur aan het werk, niet aan je enthousiasme.
Als je liever niet deze calculus leert door tokens in brand te steken op een live klantenrepo, dan is dit precies het soort orkestratiesetup dat ik bouw en afstem voor teams — je kunt zien wat ik aanneem op mijn Fiverr. De primitiefselectie de eerste keer goed krijgen is het grootste deel van de waarde.
De truc die de economie verandert: nest skills in workflows
Hier is de zet die workflows minder als een geldput liet voelen en meer als hefboom. Je kunt skills nesten binnen een workflow. Elk van de vele agents die een workflow opstart kan je bestaande herbruikbare recepten aanroepen.
Denk na over wat dat doet. Je besteedt de moeite één keer om een strakke, goed geteste skill te schrijven — zeg, een precies "score dit skill-bestand aan de hand van deze tien criteria"-recept. Dan start een workflow 41 agents op en elk draait diezelfde skill tegen een ander doel. Je krijgt het parallellisme van een workflow met de consistentie en onderhoudbaarheid van een skill. De dure, complexe laag leunt op de goedkope, simpele laag. Dat is de architectuur waar ik op uitkwam voor de audit waarmee dit bericht opende, en het is waarom de output zo schoon was — elk van die 41 agents beoordeelde volgens dezelfde rubric, omdat ze allemaal dezelfde skill draaiden.
Dit is het deel van de kosten-complexiteitsladder dat mensen missen. De treden sluiten elkaar niet uit. Het slimme patroon is het goedkoopste gereedschap dat het eigenlijke werk doet, verpakt in het dure gereedschap alleen waar je de schaal oprecht nodig hebt. Workflows erbovenop, skills eronder. Je kiest niet tussen ze — je stapelt ze.
Je kunt verder gaan en een workflow combineren met /goal — breedte en diepte samen, veel parallelle agents die elk itereren naar een doel. Het is de krachtigste orkestratie die ik heb gedraaid. Het is ook het duurste ding in dit hele bericht, met een ruime marge, en ik behandel het als een elektrisch gereedschap zonder beschermkap. De moeite waard voor een oprecht groot, oprecht moeilijk karwei. Een geweldige manier om tokens te verdampen bij iets minder.
Een korte zijsprong die niets met workflows te maken heeft: als dit alles klinkt als meer orkestratie dan je daadwerkelijke probleem nodig heeft — zeg dat je gewoon een AI-app of website wilt bouwen met wat MCP-koppelingen, niet 41 agents coördineren — dan is Lovable een veel simpelere oprit. Het koppelt MCP-servers aan en geeft je een bouwervaring die niets van dit alles vereist. Het is een ander gereedschap voor een andere hoogte. Het hele punt van dit bericht is het gereedschap matchen aan de taak, dus ik zou een hypocriet zijn als ik het niet noemde. Nu terug naar de agents.
Wat dit je daadwerkelijk kost — en hoe je weet dat het werkt
Laat me de economie onderbouwen, want "5 miljoen tokens" zonder context is ofwel angstaanjagend ofwel betekenisloos, afhankelijk van wat je aanneemt.
Het getal dat ertoe doet is niet totale tokens — het zijn welke tokens. Mijn 41-agent audit was bijna volledig input tokens, en ik draaide de scorers op Haiku. Op Anthropics gepubliceerde prijzen draait Haiku input voor een fractie van een cent per duizend tokens, dus 5 miljoen input tokens van goedkoop-model lezen is een fundamenteel andere rekening dan 5 miljoen output tokens van Opus-generatie. De les generaliseert: de kosten van een workflow worden gedomineerd door hoeveel de agents lezen, maal de prijs van het model waarmee ze lezen. Kies het model bewust. Goedkope modellen voor breed, ondiep crawlen. Dure modellen alleen voor de stukken die echt redenering nodig hebben.
Hoe weet je of een workflow de juiste keuze is voordat je het draait? Doe deze buikgevoel-check. Tel de onafhankelijke stukken. Als de taak uiteenvalt in ruwweg tien of meer brokken die oprecht niet van elkaar afhangen, zal parallellisme de orkestratieoverhead terugbetalen — dat is je groen licht. Minder dan dat, of de stukken hangen van elkaar af, en een simpelere primitief wint bijna zeker op kosten.
En zodra het draait, let op twee dingen in /workflows: het aantal agents en de kloktijd. Als het aantal agents klimt richting territorium dat je niet bedoelde — die monorepo-schaal fan-out — stop het en verscherp je scope. Als een workflow veel langer duurt dan de equivalente sequentiële taak zou hebben gedaan, was de taak waarschijnlijk niet parallelliseerbaar en heb je verkeerd gekozen. De hele belofte van breedte is snellere kloktijd door parallellisme. Als je dat niet krijgt, was de vorm verkeerd.
De realistische beloning, wanneer de vorm wel goed is: taken die een enkele agent een uur sequentieel zwoegen zouden hebben gekost, zijn in minuten klaar, omdat het werk breed was en je het liet uitwaaieren. Dat is de volledige waardepropositie. Geen magie. Gewoon parallellisme, correct toegepast, met het plan veilig buiten het hoofd van het model gehouden.
De ene beslissing die dit alles makkelijk maakt
Ga terug naar die terminalteller die voorbij 41 klom. De reden dat die run goed voelde in plaats van roekeloos was niet de technologie. Het was dat ik het gereedschap had gematcht aan de vorm van het werk: een brede, platte stapel onafhankelijke scortaken, elk dezelfde skill draaiend, resultaten samengevoegd in code, output klein. Juiste primitief, juist model, begrensde scope. Alles stroomafwaarts van die ene beslissing was makkelijk.
Dat is de hele vaardigheid hier, en het gaat eigenlijk helemaal niet over Claude Code. Het gaat over het bekijken van een taak en het stellen van één vraag voordat je ook maar een enkel commando aanraakt: is dit breed of diep, collaboratief of onafhankelijk, groot of klein? Beantwoord dat eerlijk en het gereedschap kiest zichzelf. Skill voor het kleine en herhaalde. Subagent voor de simpele zijklus. Agentteam voor het echte debat. Workflow voor de brede onafhankelijke crawl. /goal voor de diepe iteratieve grind. De dure gereedschappen om de goedkope heen gewikkeld, nooit andersom.
Dus voordat je volgende grote karwei — de codebase-audit, het brede onderzoek, de dataset waar je tegenop hebt gezien — stop en benoem de vorm hardop. Breed of diep? Dat ene woord bespaart je meer tokens dan welke instelling in de app ook. Wat is de breedste taak op je bord die je nu bestand-voor-bestand aan het doen bent?
Veelgestelde vragen
Wat zijn Claude Code dynamische workflows?
Claude Code dynamische workflows zijn een feature, gelanceerd op 28 mei 2026, waarmee Claude een JavaScript-orkestratiescript schrijft en veel onafhankelijke agents parallel draait op verschillende stukken van een taak. Het plan leeft in een extern bestand, niet in Claudes contextvenster, en agents communiceren niet — resultaten worden gecombineerd in scriptlogica. Je triggert er een door het woord "workflow" in je prompt op te nemen (vereist Claude Code v2.1.154+).
Hoe verschillen workflows van subagents en agentteams?
Workflows spawnen veel niet-communicerende agents parallel met het plan in een extern script, terwijl subagents geïsoleerde zijtaken draaien die alleen aan de hoofdsessie rapporteren, en agentteams een kleine groep zijn die wel praten en context delen om samen te werken. De schone regel: subagents lasten af, teams overleggen, workflows waaieren breed uit. Voor het diepere onderscheid over wanneer agents moeten communiceren, zie mijn gids over agentteams.
Wanneer moet ik een workflow gebruiken versus het /goal-commando?
Gebruik een workflow voor breedte — veel onafhankelijke, parallelliseerbare stukken zoals een codebase crawlen of een dataset scoren — en gebruik /goal voor diepte, waarbij één poging in een lus itereert tot een doel is bereikt. Workflows spreiden zich uit; /goal boort zich omlaag. Als de taak breed en ondiep is, workflow. Als het smal en diep is, /goal.
Hoeveel kosten Claude Code workflows in tokens?
De kosten van een workflow worden gedomineerd door hoeveel de agents lezen vermenigvuldigd met de prijs van het model dat ze gebruiken, dus dezelfde 5-miljoen-token-run is goedkoop op Haiku input en duur op Opus output. Kosten pieken wanneer prompts vaag zijn of scope onbegrensd, omdat elk van de maximaal 1.000 agents een volledige Claude-aanroep is. Begrens de scope en kies goedkope modellen voor breed, ondiep crawlen. Voor de modelkant hiervan, zie mijn review van de inspanningsniveaus van Opus 4.8.
Wat is Ultra Code-modus in Claude Code?
Ultra Code (/effort ultracode) combineert de hoogste redeneerinspanning met automatische workflow-orkestratie, waardoor Claude kan beslissen wanneer elke substantiële taak het opzetten van een workflow rechtvaardigt. Het is de meest capabele modus in Claude Code en de duurste — een enkel verzoek kan uitmonden in meerdere workflows achter elkaar. Gebruik het voor oprecht moeilijk, waardevol werk, niet als standaard.
Laten we samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (ontwerp & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
