Forked Subagents in Claude Code: Waarom Ik Geen Gewone Subagents Meer Gebruik

Forked Subagents in Claude Code: Waarom Ik Geen Gewone Subagents Meer Gebruik

Het was 1:47 ’s nachts toen ik besefte dat ik al vier uur het verkeerde probleem aan het debuggen was.

Ik zat diep in een lange Claude Code-sessie — waarschijnlijk zo’n 180.000 tokens ver — en was bezig met het inrichten van een betaalflow voor een SaaS-klant. Ik zette een normale subagent op om een specifieke controller te controleren en te beoordelen of mijn validatielogica echt deed wat ik dacht dat hij deed. De subagent kwam zelfverzekerd terug: “Ziet er correct uit. De guard op regel 47 voorkomt de raceconditie die je beschreef.”

Behalve dat het niet zo was. De guard waar ik me zorgen over maakte, zat helemaal niet in de controller. Die zat in een middleware die de subagent nooit had gezien, omdat de gecomprimeerde contextsamenvatting die middleware had teruggebracht tot iets als: “project gebruikt standaard Laravel middleware stack.” De nuance — de specifieke custom middleware die ertoe deed — was verloren gegaan tijdens de compressie.

Toen ben ik me gaan verdiepen in geforkte subagents in Claude Code. En na twee weken mijn manier van werk delegeren in lange sessies te hebben aangepast, ga ik niet meer terug.

Dit artikel is wat ik zelf graag had willen lezen op de dag dat ik /fork voor het eerst inschakelde. Dit is geen persbericht. Dit is wat er echt gebeurde toen ik het testte in daadwerkelijk klantwerk — daar waar de compressie echt pijn doet, en waar geforkte subagents nog steeds fouten kunnen maken.

De compressiebelasting waar niemand over praat

Hier is het probleem met normale subagents in Claude Code: ze erven jouw gesprek niet. Ze erven een samenvatting van je gesprek — de ingebouwde contextcompressie van Anthropic die alles verwerkt wat je tot dan toe hebt gezegd, samengeperst tot iets kleins genoeg om in het contextvenster van de subagent te passen, samen met zijn eigen taak.

Die compressie is altijd verlieslatend. Het moet wel.

Het mentale model dat ik hanteerde, klopte niet. Ik dacht dat een subagent was als een collega die je even een bericht stuurt: "hé, klein dingetje, dit is waar we mee bezig zijn, kijk er even naar." Maar in werkelijkheid was ik bezig een collega een eenpaginavoorsamenvatting van een drie uur durende vergadering te geven, met het verzoek om mee te beslissen over iets dat afhing van een specifieke opmerking die iemand op minuut 47 had gemaakt.

De samenvatting vat de grote lijnen samen. De details gaan verloren. En voor werk aan code zijn de details juist allesbepalend.

Je ziet dit terug in de GitHub-issues die het team van Anthropic bijhoudt. Er loopt een verzoek — issue #6825 — voor configureerbare overerving van system prompt en geheugen voor subagents, precies omdat het standaardgedrag te veel of te weinig informatie overdraagt, afhankelijk van wat je doet. En er is een parallelle zorg in issue #4908 over het doorgeven van context binnen een scope; in feite hetzelfde probleem vanuit een andere hoek: ontwikkelaars willen zelf bepalen wat de subagent daadwerkelijk ziet.

Dit is de kern van de spanning: een volledig contextvenster verslechtert de kwaliteit van Claude Code's besluitvorming over tijd — uit mijn eigen tests blijkt dat de nauwkeurigheid na ongeveer 200k tokens daalt, en Anthropic's eigen context management documentatie voor het 1M-venster erkent deze valkuil. De hoofdsessie moet dus slank blijven. Maar de subagent die te weinig context heeft, maakt slechte keuzes. Compressie is de middenweg, en aan elke compromis hangt een prijskaartje.

Forked subagents doorbreken deze trade-off. Ze erven de volledige gespreksgeschiedenis van de hoofdsessie, byte voor byte, en delen de prompt-cache met die sessie waardoor je niet voor elke token het volle pond betaalt. Dat is het idee. De vraag waar ik twee weken op heb ge kauwd: klopt die belofte echt?

Wat /fork Echt Doet (En Waarom Het Anders Is)

Het /fork-commando start een subagent die begint met je volledige gespreksgeschiedenis in zijn contextvenster geladen. Geen samenvatting. Geen gecomprimeerd overzicht. De daadwerkelijke berichten, de daadwerkelijke tool-aanroepen, de daadwerkelijke bestandslezingen — alles wat je tot het moment van forken hebt opgebouwd.

Cruciaal is dat de fork de prompt-cache deelt met de hoofdsectie. Dit is belangrijker dan het klinkt. Zonder gedeelde caching zou een geforkte subagent onbetaalbaar zijn — je zou twee keer betalen voor dezelfde overgenomen tokens, één keer in de hoofdsectie en één keer in de fork. Anthropics context engineering-artikel over LMCache gaf aan dat het hergebruik van prompts in Claude Code-fases op 92% ligt, en bij ReAct-achtige subagent-loops nog hoger. Forking leunt zwaar op dat hergebruik.

Het praktische kostenplaatje ziet er zo uit. Als je hoofdsectie op 180k tokens zit en je forkt, begint de fork ook met 180k tokens. Maar omdat die tokens al gecachet zijn, ligt de effectieve prijs dichter bij de cache-leessnelheden — ongeveer 10% van de normale inputprijs op Sonnet-tiers. Dus een fork die normaal gesproken zou kosten wat een prompt van 180k tokens zou kosten, kost in werkelijkheid veel dichter bij een prompt van 18k tokens in de eerste beurt, en gedraagt zich daarna als een normaal gesprek.

Dat is het deel dat de rekensom verandert over wanneer je kunt delegeren.

Er zit een subtiel maar belangrijk detail in hoe dit is gebouwd. Een recente optimalisatie van de /fork-internals schrijft per fork een pointer naar de ouderconversatie naar schijf, in plaats van het hele gesprek, met hydratatie bij het lezen. Dat is pure backend, niet zichtbaar voor de gebruiker, maar het is de reden waarom je meerdere forks kunt starten zonder dat je schijf volloopt. Deze functie is inmiddels productierijp, niet langer experimenteel.

Om geforkte subagents op externe builds te activeren, zet je de omgevingsvariabele CLAUDE_CODE_FORK_SUBAGENT=1 of schakel je de overeenkomstige optie in je settings.json aan. Zodra dit is ingeschakeld, is /fork beschikbaar als slash-commando in elke sessie, en kun je de geforkte sub direct aanspreken voor vervolgprompts, zonder terug te hoeven naar de hoofdthread.

De eerste fork die ik écht vertrouwde

Eerlijk is eerlijk — ik vertrouwde /fork niet meteen op dag één. Ik ben al te vaak teleurgesteld door features die er prachtig uitzagen op een landingspagina, maar compleet instortten bij écht klantwerk. Mijn standaardhouding is dus sceptisch.

Dit was het moment waarop ik overtuigd werd.

Ik werkte aan een design system-project — een dashboard met een Kanbanbord, een kalenderweergave en een instellingenscherm, die allemaal een uniforme visuele stijl moesten delen. Ik zat al meer dan 140k tokens diep in een sessie waarin ik een tiental componentkeuzes had gemaakt, een kleurensysteem had opgezet, een typografieschaal gekozen, en drie componenten uitgeschreven. Ik moest nu twee designvariaties van de Kanban-kaart genereren: één meer gecomprimeerd, één luchtiger, om te zien welke het beste aansloot bij de rest van het systeem.

Met een gewone subagent zou dit fout zijn gegaan. Die zou een gecomprimeerde samenvatting krijgen als “project gebruikt Tailwind, design system is donker met paarse accenten, typografie is Inter.” Dat is bij lange na niet genoeg om variaties te maken die aanvoelen als onderdeel van hetzelfde systeem. De helft van de nuance — de precieze mate van spatiëring die ik gebruikte, de specifieke schaduw-effecten, hoe ik omging met icoongroottes — zou simpelweg verloren gaan.

In plaats daarvan maakte ik een fork. Eigenlijk twee, parallel aan elkaar. Één met de prompt “genereer een compactere Kanban-kaart: behoud alles van het bestaande systeem, maar verklein de verticale ruimte met ±25% en versmal de typografieschaal één stap.” De tweede met “genereer een luchtigere Kanban-kaart: behoud het systeem, vergroot de padding en geef de kaart meer ademruimte.”

Beide forks leverden variaties op die ook écht voelden als onderdelen van hetzelfde design system, omdat ze dat hele design system geladen hadden. Niet een samenvatting. Alles. De kleur-tokens waar ik me op vastgelegd had, de componentpatronen die ik bepaald had, de spatiëringslogica waarop ik al twee uur aan het schaven was — het zat er allemaal in.

Dat was het moment waarop ik stopte met discussiëren over de feature en hem gewoon ben gaan gebruiken.

Waar Forking Z’n Geld Verdient

Twee weken intensief gebruik hebben me een ruw beeld gegeven van waar forked subagents echt het verschil maken en waar normale subagents nog steeds het juiste gereedschap zijn. Ik loop langs de patronen die zich in de praktijk bewezen hebben.

Paralleliseren van Ontwerpwerk

Dit is de use case die mij overtuigde. Wanneer je visuele of structurele beslissingen maakt die afhankelijk zijn van een systeem dat je in de sessie hebt opgebouwd, vernietigt compressie van dat systeem de outputkwaliteit. Forking behoudt dat systeem.

Ik spawn nu standaard twee of drie forks parallel wanneer ik variaties wil evalueren — componentontwerpen, API-structuren, databaseschema’s, alternatieve copy. Elke fork krijgt de volledige context plus een specifieke variatieprompt. Ik vergelijk de outputs naast elkaar. Die vergelijking heeft alleen waarde omdat alle drie forks vanuit precies dezelfde basis werken.

Geheugenconsolidatie en Samenvatting

Als je de /bytheway-opdracht of de geheugenconsolidatiefuncties van Claude Code hebt gebruikt, dan heb je al met forked subagents gewerkt — ze draaien achter de schermen. Voor deze taken is de volledige conversatie cruciaal. Een samenvatting die op basis van een gecomprimeerde recap wordt gegenereerd is slechts een samenvatting van een samenvatting, oftewel de inhoudelijke equivalent van een fotokopie van een fotokopie.

Nu ik weet wat er onder de motorkap gebeurt, gebruik ik deze functies veel agressiever. Als ik tegen een contextlimiet aanloop in een sessie die ik wil bewaren, stuur ik een /bytheway om de belangrijke beslissingen in het geheugen vast te leggen voordat ik ga comprimeren of herstarten.

Multi-Tool Parallelle Verificatie

Dit patroon heb ik ontwikkeld en het is echt nuttig. Zodra ik een substantieel stuk code heb gegenereerd, start ik twee forks tegelijk:

1. Fork A: “Genereer een Mermaid-diagram dat laat zien hoe de zojuist gemaakte codewijzigingen door de request lifecycle lopen. Geef alles wat is veranderd een andere kleur.”

2. Fork B: “Doe een web search om te controleren of de specifieke API-patronen in de codewijzigingen nog steeds best practice zijn voor [framework] anno 2026. Citeer alles wat verouderd lijkt.”

Beide forks hebben de complete sessiecontext, dus beide weten exact over welke code ik het heb. De diagram-fork geeft me een visuele sanity check. De verificatie-fork vangt de gevallen waarin mijn spiergeheugen een patroon toepaste dat drie jaar geleden idiomatisch was, maar inmiddels is achterhaald. Zo krijg ik twee onafhankelijke perspectieven op dezelfde wijziging, parallel gegenereerd, zonder mijn hoofdsessie met extra output te vervuilen.

Beheersing van Zijpaden

Deze is subtieler, maar belangrijk voor de gemoedsrust. Soms heb ik een nevenvraag die interessant maar off-topic is. “Wacht — als we hier een ander ORM-patroon hadden gebruikt, zou de hele flow dan eenvoudiger zijn?” Normaal gesproken ontspoort zo’n zijpad de hoofdthread voor twintig minuten of raak ik het kwijt om die ontsporing te voorkomen.

Forked subagents geven je een helder antwoord. Fork, stel de zijvraag, onderzoek het what-if-scenario. Als het antwoord waardevol is, breng je het inzicht terug naar de hoofdsessie. Is het een doodlopende weg, dan doe je /rewind en is de fork verdwenen. De hoofdconversatie weet van niets.

Dit is niet alleen een functie, maar een gedragsverandering in hoe ik Claude Code gebruik. Ik onderzoek nu veel meer zijvragen, omdat de kosten daalden van “potentiële ontsporing” naar “gratis zijpad, gooi weg als het niks oplevert.”

Wanneer forken de verkeerde keuze is

Forken is niet altijd de juiste zet. Het is een valkuil om te denken dat meer context altijd beter is, en ik ben er zelf ook ingetrapt in de tweede week dat ik deze feature gebruikte.

De valkuil is bias. Een geforkte subagent heeft alles gezien wat je in de sessie hebt gedaan — inclusief de code die je zojuist geschreven hebt, de architectuurkeuzes die je hebt gemaakt, de libraries die je hebt gekozen. Als je een fork vraagt om die code te reviewen, krijg je geen frisse blik. Je krijgt opnieuw jouw eigen blik, gewoon draaiend als een apart proces. De fork onthoudt waarom je iedere beslissing nam, en bevestigingsbias sluipt er vanzelf in.

Dat is relevant bij code reviews. Een goede code review haalt net dát eruit waar jij niet aan gedacht had, en die kan dus alleen komen van iemand die niet jouw denkrichting heeft gevolgd.

Ik heb dit direct getest. Ik schreef een batch authenticatie-gerelateerde code en vroeg een geforkte subagent om te reviewen. De fork kwam terug met cosmetische suggesties — variabelnamen, een kleine aanpassing in een docstring, een lichte refactor. Daarna vroeg ik een normale subagent (frisse context, geen sessiegeschiedenis) om exact dezelfde code te reviewen. De normale subagent merkte direct op dat ik een token niet in constante tijd vergeleek, wat een serieuze security bug opleverde die de fork compleet over het hoofd had gezien omdat, in de context van de fork, de code “redelijk leek gezien de bestaande patronen”.

Daar hou ik me dus aan:

• Fork als context een voordeel is. Denk aan ontwerpconsistentie, geheugenopbouw, workflows met meerdere stappen die historie vereisen, of het exploreren van zijsporen.
• Fork niet wanneer context juist een nadeel is. Code reviews, security audits, adversariële tests, of alles waarbij nieuwe aannames belangrijk zijn.

Normale subagents mogen nog steeds aanschuiven. Ze hebben simpelweg een andere rol.

De Forked vs Normaal Analyse

Hier is de vergelijking die ik op dag één had willen hebben, samengevat tot iets wat je direct kunt toepassen bij het maken van een keuze.

De belangrijkste rij is die van "Beste voor". Gebruik /fork niet alleen omdat het een nieuwe functie is. Gebruik het omdat de taak echt baat heeft bij contextcontinuïteit. Anders betaal je een bias-taks zonder voordeel.

Inschakelen en Echt Gebruiken

Als je forked subagents nog niet hebt ingeschakeld, is dit de kortste weg.

Open je Claude Code settings.json — meestal te vinden op ~/.claude/settings.json voor gebruikersscope of .claude/settings.json in de root van je project. Stel óf de omgevingsvariabele CLAUDE_CODE_FORK_SUBAGENT=1 in in je shell-profiel, óf voeg de equivalente flag toe aan je settings JSON. De exacte sleutelnaam is door de versies heen gewijzigd, dus check de laatste release notes van Claude Code als alleen de omgevingsvariabele niet genoeg is.

Eenmaal ingeschakeld, is /fork beschikbaar als slash-commando in elke sessie. Typ het, voeg je prompt toe, en je hebt een fork. Je kunt de fork direct aanspreken voor vervolgrondes door berichten te prefixen, en je kunt /rewind gebruiken om een fork die nergens toe geleid heeft te verwijderen.

Enkele operationele tips uit twee weken intensief gebruik:

Fork bewust, niet automatisch. In de eerste week forkte ik voor alles. Dat was niet handig. Forken brengt een impliciete bias-kost met zich mee bij reviewtaken, en het voegt mentale overhead toe omdat je nu twee of drie threads moet bijhouden. Ik ben nu uitgekomen op drie à vier forks per serieuze sessie — op momenten waarop het echt zinvol is om het volledige contextpad te behouden.

Gebruik parallelle forks voor convergentie. Wanneer je twijfelt over een beslissing, start dan twee forks met tegenovergestelde aannames en vergelijk. Ik deed dit onlangs toen ik neigde naar óf servercomponenten óf clientcomponenten voor een specifieke Next.js-pagina. Twee forks, twee argumentaties, output naast elkaar. Het antwoord was na vijf minuten lezen glashelder.

Let op de /rewind-gewoonte. /rewind is de nooduitgang die experimenteren goedkoop maakt. Als je hem zelden gebruikt, fork je vermoedelijk te weinig om echt te exploreren. Forks die doodlopen moeten worden teruggedraaid, niet betreurd.

Combineer forks met normale subagents voor adversariële checks. Nadat een fork een oplossing heeft gegenereerd, geef je hetzelfde probleem aan een normale subagent zonder context. Als ze het eens zijn, mag je jezelf meer vertrouwen. Als ze het oneens zijn, is dat informatiewaarde — onderzoek waarom het frisse perspectief iets ziet wat de contextbeladen fork over het hoofd zag.

Wat Ik de Eerste Week Verkeerd Deed

Ik wil open zijn over de missers, want de feature is krachtig genoeg dat je al snel de neiging krijgt hem te oversellen.

De eerste fout: ik forkte te veel. Ik forkte voor code-reviews, wat achteraf gezien dom was. De fork, die zich alles herinnerde van de code die ik net had geschreven, zat in feite alleen maar mijn eigen werk goed te keuren. Boris Cherny's talk over Claude Code-workflow maakt duidelijk dat verse context soms juist hét nut is van een subagent – en dat advies negeerde ik volledig.

De tweede fout: ik had niet door hoe belangrijk cache warming is. De eerste fork in een sessie betaalt daadwerkelijk een flinke prijs om de overgeërfde context te cachen. Latere forks zijn goedkoop. Als je maar één fork opzet voor een kleine taak, benut je de cache eigenlijk niet zoals de feature bedoeld is. Bundel je forks waar mogelijk – als je weet dat je drie parallelle verkenningen nodig hebt, spawn ze dan vlak na elkaar.

De derde fout: ik werd gemakzuchtig over de sessieduur. Geforkte subagents lossen het fundamentele probleem niet op dat een hoofdsessie van 400k tokens gewoon een vaag-denkende sessie is. Ze verschuiven alleen een deel van het werk van de hoofdsessie naar de forks. Als je hoofdsessie opgeblazen is, zijn forks die je daaruit maakt dat óók. Op een gegeven moment moet je nog steeds compacten, een checkpoint aanmaken, of gewoon opnieuw beginnen. Mijn eerdere write-up over 1M context management in Claude Code gaat dieper in op het snoeien van sessies.

De feature is geen excuus voor slechte sessiehygiëne. Hij beloont juist goede sessiehygiëne door delegatie daadwerkelijk nuttig te maken binnen goed beheerde sessies.

Het patroon dat bleef hangen

Van alle workflows die ik heb geprobeerd, is er één blijven hangen en inmiddels reflexmatig geworden.

Wanneer ik diep in een build zit en op het punt sta een beslissing te nemen die fundamenteel voelt — “moet ik deze library gebruiken of mijn eigen bouwen?”, “moet deze API REST zijn of iets anders?”, “generaliseert deze component-architectuur, of schilder ik mezelf in een hoekje?” — dan fork ik tweemaal. Twee parallelle forks, elk aan één kant van de beslissing, elk gevraagd om hun argumenten te geven met volledige sessiecontext.

Vijf tot tien minuten later heb ik twee korte memo’s. Ik lees ze allebei. Het juiste antwoord is meestal direct duidelijk, en belangrijker nog: de redenatie is direct duidelijk. Ik krijg niet alleen een aanbeveling — ik krijg het onderbouwde verhaal voor elke optie, beoordeeld tegen de specifieke context van wat ik al gebouwd heb.

Dit heeft een oude gewoonte vervangen: een bevriende developer aanschieten om samen zo’n beslissing door te nemen. Die vriend was niet altijd beschikbaar, kende de context van het project niet, en had zijn eigen biases. De twee forks zijn altijd beschikbaar, kennen de projectcontext precies omdat ze de projectcontext zijn, en hun voorkeuren zijn transparant omdat ik de prompts heb geschreven.

Dat is geen kleine verandering. Dat is een echte verschuiving in hoe ik technische beslissingen neem bij soloprojecten.

De Test Die Ik Vanavond Zou Doen

Als je tot hier hebt gelezen en je hebt /fork nog niet ingeschakeld, is dit wat ik voor het slapengaan zou doen.

Open je Claude Code-instellingen, zet CLAUDE_CODE_FORK_SUBAGENT=1 aan en herstart de sessie. Kies een project waar je vandaag al een paar uur aan hebt gewerkt — ergens voorbij de 80k tokens context. Bedenk een vraag die je al een tijdje bezighoudt over dat project, iets dat je nog niet hebt opgezocht omdat het te veel als een zijspoor aanvoelde.

Typ /fork, stel de vraag en kijk wat er terugkomt.

Vergelijk vervolgens wat je krijgt met wat je via een normale subagent zou hebben gekregen — je kunt daadwerkelijk dezelfde prompt daarna via een normale subagent draaien en het antwoord naast elkaar leggen. Let op wat de fork wél oppikt dat de normale subagent mist. Let op waar het frisse perspectief van de gewone subagent juist nuttiger was dan het volledige geheugen van de fork.

Na de tweede of derde fork heb je door wanneer deze functie zijn waarde bewijst, en wanneer niet. Dat instinct is waar je eigenlijk aan werkt. Het commando is eenvoudig. Het oordeel over wanneer je het inzet, is de vaardigheid.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io